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In this Issue 



The Digital Data Storage or DDS format for tape drives was developed in 1989 to 
meet the need for high-capacity, compact tape backup for network servers and 
small multiuser systems. The DDS standard is based on the Digital Audio Tape or 
DAT standard and has been extended as backup capacity requirements have 
increased. DDS-2 drives have recently become available, and higher-capacity 
DDS-3 and DDS-4 specifications have already been approved. DDS-2 drives can 
store four gigabytes of data on a single cartridge, or typically eight gigabytes 
with 2-to-l data compression. The HP C1533A DDS-2 tape drive can record a full 
DDS-2 cartridge in just over two hours, running at a data transfer rate of 510 
kilobytes per second. This is almost an hour faster than typical DDS-2 drives. As 
explained in the article on page 6, achieving this performance required improvements in tape material, tape 
length, tape thickness, read and write heads, drum design, and linearity measurement and adjustment. 

For many systems, eight gigabytes isn't enough, and it isn't convenient for the typical user to change 
cartridges during the backup, which must often be done at night. The HP C1553A DDS tape autoloader 
was developed to meet this need. As Steve Dimond tells us in the article on page 12, the size constraints 
gave the designers their major challenge. The autoloader had to fit into a standard SP/t-inch peripheral 
enclosure (about 5.75 inches wide), incorporate the four-inch-wide HP C1533A tape drive, hold as many 
tapes as possible, and be reliable and ergonomic. "As many tapes as possible" turns out to be six, giving 
the autoloader a typical capacity of 48 gigabytes with 2-to-1 data compression. Different strategies for 
using this capacity for network backup are discussed in the article. The complex retry algorithms required 
for controlling the autoloader are defined in state tables, which are generated by an automatic tool that 
greatly increases readability and maintainability, as explained in the article on page 21. In a companion 
article, on page 27, firmware designer Mark Sirnms shares with us his experience using different ap- 
proaches to the implementation of state machines, exploring the advantages and disadvantages of each 
approach. 

Debuggers are software tools that are used by software developers for finding bugs in programs and for 
analyzing programs. The debugger described in the article on page 33 is called HP DDE, which stands for 
distributed debugging environment, meaning that this debugger can debug programs running on remote 
computers. It's an event-based debugger, which means that it responds to user-specified events that occur 
during program execution. It consists of a main debugger that communicates with several modules called 
managers, which handle dependencies on specific languages, object code formats, target platforms, and 
user interfaces. This modularity has made it easy to retarget the debugger to many different languages 
and computer platforms, both HP and non-HP. 

Most engineers are familiar with Fourier analysis, in which a time-varying voltage is expressed as the 
sum of a set of sinusoidal basis functions of different frequencies and amplitudes. Wavelet analysis, 
described in the article on page 44, is similar, but the basis functions, called wavelets, are not sinusoidal 
and are localized in time and frequency. The properties of wavelets make them useful for processing 
nonstationary signals such as a sum of gliding tones or a sum of three signals that start at different 
times. The article gives an overview of wavelet analysis and describes a software toolbox created by 
HP Laboratories Japan to aid in the development of wavelet applications. 

Test vector is a test-engineer term for a pattern of ones and zeros that an automatic tester applies to the 
inputs of an integrated circuit or a printed circuit assembly to make sure that it works. Generating and 
verifying test vectors is a nontrivial process that's carried out with the aid of specialized software tools 
and can take six months or so to complete. As explained in the article on page 55, engineers at one HP 
laboratory have been able to reduce this time to four months, thanks to five techniques that mainly verify 
that the test access port is functioning properly. 
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It's known that detecting and fixing software bugs early m the development cycle is much less costly 
than dealing with them late in the cycle. Software inspections are one means for early bug detection. 
One HP software laboratory has used data collected during inspections and testing to estimate the value 
(expressed as the return on investment) of inspections and early testing. Their results show a return on 
investment of 787% for inspections, compared to 229% for testing Details are in the article on page 60. 

The latest generation of high-performance microprocessor chips operates at clock rates up to 150 
megahertz and leaves little room for imprecision or uncertainty in the clock delivery system. Using Intel's 
Pentium'" chip as an example of this new class of processors, the article on page 68 shows that the 
jitter tolerance for the clock delivery system can be as low as 50 picoseconds, making it essential to use 
a low-jitter signal source such as the HP 8133A pulse generator when making measurements on such 
systems. The HP 8133A's jitter specification of five picoseconds Irms) ensures that most of the measured 
jitter comes from the clock delivery system and not from the signal source. 

The report on page 80 presents some recent results of an HP Laboratories project aimed at modeling 
and simulating a manufacturing enterprise. The goal of this ongoing research is to learn to predict the 
likely results of changes using sound engineering principles and techniques. The results in this report 
are from simulation experiments using a model called the Simple Model because of its structural sim- 
plicity. Despite its simplicity, the model displayed complex dynamic behavior and produced unexpected 
results. The author suggests that application areas for enterprise modeling and simulation include esti- 
mating the effects of incremental improvements, studying the impacts of process changes, generating 
enterprise behavior information, and increasing the chances for success of reengineering efforts. 

R.P. Dolan 
Editor 



Cover 

An exploded view of the interior of the HP C1553A DDS tape autoloader, showing the C1533A DDS-2 tape 
drive (shiny rectangle) and the small amount of space around it that was available to the autoloader 
designers. Also shown is the six-cartridge autoloader magazine in the front-panel door. 



What's Ahead 

Lightwave topics will dominate the February issue with twelve articles on new products, devices, and 
techniques. We'll also have an article on a new sequencer architecture that greatly reduces the time 
required to write tests for serial digital devices, and several articles on aspects of IC design from the 
1994 HP Design Technology Conference. 
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Fast DDS-2 Digital Audio Tape Drive 



Running at a data transfer rate of 510 kbytes/s, the HP C1533A tape drive 
can record a full 4-Gbyte DDS-2 cartridge in just over two hours, almost 
an hour less than typical DDS-2 drives. Its development required 
improvements in tape material, length, and thickness, new read and write 
heads, a new drum design, and new methods for linearity measurement 
and adjustment. 

by Damon R. I'jvarosy 



Like all aspects of computing today, the face of mass storage 
is changing rapidly. < )nly a few short years ago, gigabytes of 
disk storage was the domain of large computer systems, 
housed in computer rooms with dedicated staff to look after 
the equipment. Personal computers that had more than 100 
megabytes of disk storage were a rarity, and networks were 
just coming of age. The individual computer user rarely con- 
sidered backup. Critical data was kept on huge computer 
systems and backup to tape was handled by die MIS depart- 
ment. The odd file on the PC that was important could be 
saved on a diskette. 

Times have changed rapidly. Individual P( 's with several 
hundred megabytes of disk storage are common. Network 
servers for PCs and workstations have multiple gigabytes of 
disk storage. The data on these disks is critical to the com- 
pany's business. High-performance, high-capacity backup 
solutions that fit the needs of today's computer systems arc 
essential. 

The same technologies that are propelling disk drive capac- 
ity and performance are also being applied to tape drives. 
Tape drives that meet the backup needs of the individual PC 
user are available using the DC2000 minicartridge — for ex- 
ample, the IIP Colorado Memory Systems Jumbo 250 and 
Jumbo 700 tape drives. However, the backup needs of the 
network server are far greater. These larger backups also 

DOS DDS-DC DDS-2 

11389) (1991) (1993) 



require improved performance to complete the data backup 
in a reasonable time. 

The Digital Data Storage (DDS) formal standard was devel- 
oped by HP and Sony in the late 1980s to establish a capacity 
and performance point that would serve the emerging net- 
work server market as well as the more established small 
multiuser systems market. The DDS format standard is 
based on the Digital Audio Tape (DAT) standard, which uses 
4-mm-wide tape. Tape drives that employ the DDS format 
standard are therefore often referred to as DAT or -l-mm 
tape drives. 

In HP DAT drives, lossless data compression was added 
later to the DDS format Standard using an I IP-developed 
method called DCLZ, 1 an implementation of a technique 
known as Lempel-Ziv data compression.- DCLZ effectively 
doubled the capacity and performance of the lape drive, and 
at the same time, longer tapes were added. Four gigabyt es 
could then be stored on a single DDS tape. Further exten- 
sions to the DDS formal standard thai will allow the Dl IS 
format to serve I he backup needs of network servers 
through the end of the 1990s have been agreed lo by the 
DDS manufacturers group (see Fig. 1). 

The HP C1533A DDS-2 tape drive (Fig. 2), introduced in 
1993. stores eight gigabytes of data (typical capacity 
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Fig. 2. Tin' HP G1533A DDS-2 tape drive has a native-mode data 
transfer rate of 510 kbytes/s, 40% faster than olJier designs. It re- 
cords on high-capacity -Mibyte DDS-2 cartridges or on earlier DDS 
media. 

achieved using the DCLZ data compression standard) and 
lias a data transfer rate more than 2."> times that previously 
available on DDS tape drives. The HP C1533A not only reads 
and writes tapes based on the DDS-2 format standard, hut is 
also able to read and write tapes based on the original DDS 
forma) standard to provide compatibility with the large 
installed base of DDS tape drives already in existence. 

The DDS-2 format standard calls for the data to be written 
on tracks that are nominally 0.1 |im wide as opposed to the 
previous DDS format standard, which used a I3.6-um track 
width. The DDS-2 format standard also makes use of tapes 
that are 120 m long rather than the previous 00-m and 60-m 
tapes. These changes, defined by the DDS-2 format stan- 
dard, along with a data transfer rale increase to 51(1 kbytes/s 
from 183 kbytcs/s (the data transfer rate seen by the user is 
effectively doubled to over 1 Mbyte/s by the use of data 
compression) required numerous technical developments. 

Media 

The media used for DDS-2 are an enhancement of the exist- 
ing DDS 60-m and 00-m media. Physically, all three cartridges 
look similar; they use the same cartridge shell and are all 
designed lo meet the same environmental and data reliabil- 
ity sppcifical ions. What differentiates them, apart from the 
packaging, is the length of lape in the cartridge shell and the 
signal characteristics Or recording properties of the media. 
The lape drive differentiates between the cartridge types by 
the use of recognition holes in the cartridge shell. 

The longer tape length is achieved by reducing the total 
thickness of the lape so that the lape pack volume is Ihe 
same for 120 m as for (ill m and 00 m. Fig. 3 shows Ihe rela- 
tive thicknesses of the three DDS media types and a simpli- 
fied view of the construction of the tape. To provide optimal 
head-to-tape contact when switching between Ihe different 
tape thicknesses (Hie drive needs lo read and write DDS-1 
tapes as well as DDS-2 tapes) the stiffness of Ihe tapes needs 
I" be matched as closely as possible. However, because the 
relationship between lape thickness and stiffness is a cubed 
law, use of Ihe same base film material is nol possible. A 
new base film material, polyamide or PA. has been developed. 
It has high stiffness, and by careful design of ihe heads and 
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Fig. 3. DDS tap«' lypi-s. MP = in-tal panicle PET = polyethylene 
teralhalate. PEN = polyethylene naphtalate PA = polyamide. 

drum, the ability to switch from one lape type to another 
can be optimized. 

The 120-m tape, at 6.5-uni total thickness, offers the thinnest 
media currently in use in the data recording industry- This 
has necessitated improvements in die accuracy of the tape 
guidance system within the tape mechanism and in the tape 
motion tension control servo of the mechanism to prevent 
media damage. 

The use of thinner tracks reduces the overall system signal- 
to-noise ratio and the tape was called upon to make a con- 
tribution to reducing the deficit. An increase of +3 dB over 
the existing DDS media was needed. Existing (i0-m and 00-m 
media use metal panicle ( MP) coatings. To meet the addi- 
tional signal requirements an enhanced MP tape has been 
developed and has been designated MP+. By using a combi- 
nation of magnetic particle size reduction, increased coer- 
eivity. increased reinanence. and reduced surface roughness 
of Ihe media, the additional signal requirements were 
achieved. 

The higher head-to-tape speed of the HP C1533A DDS-2 tape 
drive compared to previous DDS drives places additional 
Constraints on the media. Without efficient lubrication the 
surface of the media is damaged reducing the life of ihe 
media. There is also the possibility of ihe heads becoming 
clogged with debris from the media. To reduce this effect 
the lubrication has been modified for DDS-2. 

Heads 

The changes needed for DDS-2 also called for modifications 
to the heads. A DDS lape drive has four heads mounted on a 
rotating drum. Two heads an 1 used for writing and two for 
H ading. The lape is w rapped mound ihe drum over an angle 
thai is nominally 00 degrees (see Fig. 4) so that only one 
head is in contact with ihe lape at any given time. 

During a write, the lirsl write head (designated Ihe A write 
head) contacts Ihe lape and data is written with an azimuth 
angle of +20 degrees. The firsi read head (designated the A 
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Direction ol Rotation 



Metal Layer 
(Sendust) 





Fig. 4. The DDS tape drive lias four heads 111011111011 on a rotating 
drum. Only one head at a time is in contact with the media. 

read head) contacts the tape next to verify the previously 
written data. The second write head (designated the B write 
head) contacts the tape next to write tlala with an azimuth 
angle of -20 degrees. The second read head (designated the 
B read head) contacts the tape next to verily the data pre- 
viously written by the B write head. During this process the 
tape is moved forward to produce data on the tape as shown 
in Fig. 0. 

To accommodate the higher coercivity of I he DDS-2 tape 
media the write head was changed from a Set id ust t -based 
head to a metal-in-gap (MIG ) style ferrite-based head (see 
Fig. 6). The MIG head ensures that the magnetic coating on 
the tape is fully saturated during the write process. Sendust 
is still used in the head, but only for the gap metal and not as 
tin* bulk material. 

The read head required several changes to meet the needs of 
the HP C1533A. The first was to change from a Sendust- 
based head to a ferrite-based head. This was necessary to 
maintain the nominal head life specification of 6000 hours. 
Since the HI' C1533A has a data transfer rate that is 2.87 
times the previous generation of DDS tape drives, the head 
is in contact with the tape media 2.87 times more during thai 
6000 hours. The ferrite-based head is harder than the Sen- 
dust-based head and meets the life requirements. 

The second change to the read head was to the width. The 
nominal width of the read head for I he DDS format standard 
was 20.4 um. A read head of this widlh on a 9.1-um wide 
DDS-2 track would allow too much adjacent I rack noise to 

t Sendust is an alloy of 85% Fe. 6% Al, and 9% Si It was developed at the University ol Sendai, 
Japan 



Data Written by the A Head 



Data Written by Ihe B Head 




9.1 11m 



6 = 22 39" 



Fig. 5. DDS-:2 track format on tape. 




Fig. 6. The HP C1533A tape drive lias metal-in-gap lerrife-based 
write heads. 

be picked up, thereby reducing the signal-to-noise ratio below 
an acceptable level. At first glance il woidd seem that a read 
head width of 9.1 um (equal to Ihe nominal written track 
wMth) would be optimum (maximum on-lrack signal pickup 
with minimal adjacent-track noise pickup). This would be 
valid if the Hacks were all perfectly straight. However, the 
DDS-2 Standard c alls for the tracks to be straight wilhin ±2.5 
um over the length of the Hack (called linearity) lo allow for 
mechanical tolerances in I lie tape chive. While a 0.1-uni-wide 
read head would provide an excellent signal-to-noise ratio 
on a perfectly straighl DDS-2 written track, it would not be 
able to read a worst-case DDS-2 written track that was writ- 
ten by a different drive (see Fig. 7). In t his case, the read 
head would have a large adjacent-track noise pickup with a 
relatively small on-irack signal pickup. Since the ability lo 
interchange tapes between lape drives was an important 



DDS-2 Written 
Track with Maximum 
Deviation of 2.5 urn 



Nominal Track 
Center Line 




Path of DDS-2 
Read Head with 
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Deviation of 
2.5 um Opposite 
to the Write 




9.1 inn 

Fig. 7. Effects of tape and drive nonlinearity when a track written 
by one drive is read by a different drive. 
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consideration in the design of the HP CI 533 A tape drive, a 
balance needed to be struck to achieve the Optimum read 
head width. A 12-nm read head width was specified through 
the use of computer modeling of the effect of adjacent-track 
noise on signal-to-noise ratio. Experiments verified the 
performance of the 12-um head. 

Drum Design 

The next major challenge came in the drum design. The 
increase in the data transfer rate to 510 kbytes/s from 183 
kbytes/s required an increase in the drum rotation speed, to 
5737 r/min from 2000 r/min. The major issues to contend 
with were drum bearing life, acoustic noise at the higher 
rotation speed, and excessive air between the drum and the 
tape. Excessive air would force the tape too far away from 
the drum, resulting in reduced signal levels because of loss 
of contact between the head and the tape. 

A great deal of work has already gone into bearing life and 
acoustic noise in high-rotation-rate spindle motors for disk 
drives. The key to bearing life is the proper choice of lubri- 
cants. By using the same high-performance lubricants that 
are found in disk drive spindle motors, we were quickly able 
to meet the bearing life requirements of the HP 01533A tape 
drive. 

The acoustic noise generated by the drum is largely a func- 
tion of the control system. The control algorithm used in the 
HP C1533A tape drive reduces the high-frequency content of 
the control signals so that the acoustic noise of the HP 
C1533A is comparable to previous-generation DDS tape 
drives. 

The problem of excess air between the drum and the tape 
required the development of techniques to bleed away the 
excess air to ensure that proper head-to-tape contact was 
maintained. Several techniques were prototyped and carefully 
measured by HP Laboratories for their impact on tape defor- 
mation. Among the techniques prototyped was a "window- 
less" drum, in which there is a gap between the lower, sta- 
tionary section of the dram and the upper, rotating section of 
the drum. The gap provides a path for the air to bleed away 
and eliminates die need for a "window" around the head. A 
second technique prototyped was a standard window style 
drum with a small chamfer along the bottom edge of the 
upper rotating section of the drum to provide the necessary 
air bleed (see Fig. 8). 

In the end, the window style drum using a chamfer on the 
lower edge of the rotating section of the drum was found to 
be the best solution, ensuring that the tape was not damaged 
while providing an easily manufaeturable solution to the 
problem of excess air between the drum and the tape. 

Linearity 

As previously mentioned, the DDS-2 specification calls for a 
maximum deviation from a straight line of ±2.5 um for a 
w ritten track. This specification is referred to as linearity. 
The linearity of the previous generation of DDS tape drives 
was measured and found to have a mean value of 3.7 um and 
a standard deviation of 0.7-1 uni. To meet the DDS-2 Specifi- 
cations, an intensive research activity was undertaken at III' 
Laboratories. Thai research determined that I lie linearity 
measurement and adjustment process would have to I"' 
changed to meet the DDS-2 specifications consistently. 



Previously, linearity was measured by writing a tape, physi- 
cally cutting out a section of that tape, developing the tape 
using ferrofluids to be able to see the written tracks, and 
then measuring the tracks under a microscope. This tech- 
nique suffers from two problems. First, the measurement 
error associated with the technique was found to be up to 
2 urn. Second, the technique did not allow the linearity to be 
measured in real time while adjustments to the guides were 
being made on the production line. 

The problent of measurement error was tackled by develop- 
ing an automated optical measurement system, I'sing optical 
pattern recognition software, the system automatically finds 
special written patterns on the tape. A precision coordinate 
measurement system measures the track position relative to 
the edge of the tape. The system is calibrated with a chrome 
optical standard and a measurement accuracy of ±0.15 um is 
achieved. 

This optical measurement system is used to measure the 
absolute linearity of tapes. These tapes are then used as a 
reference for a real-time measurement system in produc- 
tion. Special patterns written on the tape are used by the 
tape drive under test to measure its own deviation along the 
track relative to the tape in the drive. By subtracting out the 
measured linearity deviation of the tape in software, an ac- 
curate real-time measurement of the linearity of the drive 
under test is achieved. It is then possible for a production 
operator to adjust the tape guides for minimum linearity 
deviation as pail of the standard production process. The 
use of these linearity measurement and adjustment methods 
has allowed HP to reduce the mean linearity deviation in 
production to 1.4 um with a standard deviation of 0.33 um, 
well within the DDS-2 specifications. 

Performance 

The network server market that the HP C1533A tape drive is 
designed to serve requires high performance as well as high 
capacity. The data transfer rate of 510 kbytes/s is an impor- 
tant factor in the performance of the HP C1533A tape drive 
since it defines the maximum rale at which data (after com- 
pression) can be written to or read from the tape. The actual 
performance the user will see in a system is a function of at 
least thin een factors. Some of these factors are a funclion of 



Upper Drum 
(Rotating) 




Lower Drum 
(Slalionaryl 

Fig. 8. Tm si vies of dnims with gaps to bleed off excess air between 
the drum and the tape In each case, four heads are spaced evenly 
around the drum, hut only the one nearest the observe! is shown m 

this drawing The diagonal line aa the lower drum la the path of the 
lower edtfc of the tape iii this helical scan system 
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Performance Factor 

Data transfer rate 



Ihe tape drive, but niany are dictated by the system using 
the tape drive. The major performance factors, along with 
the corresponding controlling functions, are listed below. 

Cunt rolling Function 

Tape drive if desired data 
transfer rale is greater 
than maximum tape drive 
transfer rate 
Computer system if desired 
data transfer rate is less 
than maximum tape drive 
transfer rate 
Maximum data compression Tape drive 
ratio that maintains 
maximum tape drive 
transfer rate 
Data compression ratio I >aia 

Main buffer size Tape drive 

SCSI transfer rate Limited to the maximum SCSI 

transfer rate that both the 
tape drive and the computer 
system can achieve 
Computer system 



Data transfer size 



The architecture of the IIP C1533A controller is outlined in 
Fig. 9. 

An examination of the write process is instructive in Under- 
standing the potential performance limiters. The following 
are the major steps in the write process. 

1. Computer system negotiates SCSI transfer rate with the 
tape drive. 

2. Computer system establishes transfer size. 

3. Computer system transfers data to the tape drive. 

4. Tape drive compresses the data through the data com- 
pression processor and moves the data into ( he main buffer. 
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Fig. 9. Block diagram of the HP C1533A tape drive controller. 




5. Format processor divides the data into DDS formal slan- 
dard groups and adds access and indexing data to enable 
high-speed search and retrieval and error collection fields 
to maintain data integrity on reads. 

6. DDS formal data is written onto Ihe tape. 

To achieve maximum performance, it is essential that DDS 
formal data is available lo write onto Ihe tape at all limes. If 
no data is available, the tape drive will have to stop writing 
data and wait until data is available before restarting the 
write process. The tape will also have to be repositioned 
before the next write can begin. The fonnat processor must 
of course have the ability to take the dala from the main 
buffer, convert the data into the DDS formal and compute 
Ihe error correc tion values in real lime or Ihe tape drive will 
never achieve its full performance. 

The main buffer performs a speed matching function, giving 
the data compression processor the necessary freedom to 
output data at a varying rate while keeping the lape drive 
streaming. Modeling demonstrated that a huffer size of 1M 
bytes is sufficient to maintain Ihe performance of the HP 
C1533A tape drive in most applications. 

The maximum speed at which Ihe data compression proces- 
sor can take uncompressed input data and output it as com- 
pressed data is another factor in the performance picture. 
The more compressible the data, the faster the data Compres- 
sion processor needs to be to maintain an output rate that is 
fast enough to keep the tape drive streaming. An average 
compression ratio of 2 to 1 is the accepted industry norm for 
typical computer dala. However, within a large backup, the 
compression ratio of individual files will vary tremendously. 
By studying a huge number of backups, we were able to es- 
tablish that the data compression processor needs to be capa- 
ble of about 4-to-l compression at full Output rate to maintain 
an overall 2-to-l compression rate. We therefore designed 
the data compression processor for the HP C1533A to meet 
this requirement. 

The last major piece in Ihe performance picture has to do 
with the ability of the computer system to move data to the 
tape drive. To get the maximum performance from the tape 
drive, it is important that the computer system provide the 
dala as fast as the lape drive needs it. The maximum rate at 
whic h the data can then be transferred to Ihe tape drive is 
determined by the negotiated SCSI transfer rate and the 
transfer size thai the computer system establishes. The SCSI 
transfer rate is the lower of the computer sysl em and tape 
drive maximum rates. If the computer system's maximum 
SCSI transfer rate is less than ihe tape chive's maximum 
SCSI transfer rate, the SCSI transfer rate used will be that of 
the computer system. The slower the transfer rate, Ihe less 
time there is to cover any system overhead. Additionally, if 
the computer system establishes a small transfer size, the 
data transfer will occur in small increments. Since each 
transfer has overhead associated with it, small transfer sizes 
will have relatively more overhead wiuch will likely reduce 
the performance of the lape backup (see Fig. 10). 
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Fig. 10. Maximum <Iata transfer rate of (he HP C1533A tape drive at 
2:1 data compression ratio (variable- modi-, writing from memory on 
an HP 9000 Model 720 computer). 
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DDS-2 Tape Autoloader: High-Capacity 
Data Storage in a 5 Winch Form Factor 



The autoloader holds six 4-gigabyte cartridges. With data compression, it 
can back up typically 48 Gbytes of data overnight or 8 Gbytes every day 
for six days, unattended. 

by Steven A. Dimond 



The trend from centralized computing data centers to PCs 
and client -server networks has led to increased local or 
semilocal data storage and backup. As discussed in the pre- 
ceding article, DDS tape drives are designed to meet these 
requirements. However, as network server disk capacities 
increase above the capacity of a single DDS tape (8 giga- 
bytes for DDS-2, compressed), or if manipulation of the 
backup tapes becomes a chore, then there is a requirement 
for a larger storage device. 

The type of person who carries out the backup has also 
changed with these trends in computing. The centralized 
data center had trained, full-time operators, whereas the 
network administrator or workstation user may not be for- 
mally trained and will want to spend (he minimum time and 
effort completing the backup. 

These requirements for storage capacity and ease of use have 
led to a need for an automated, easy-to-use, large-capacity 
tape device. 

One way to add significant capacity at modest cost is to use 
a changer mechanism (robot) to select a tape from a library 
of tapes and put it into the tape drive. The changer mecha- 
nism may only double or quadruple the cost of the tape 
drive unit , but the capacity can increase many times more 
than this. There are tape libraries that have from 10 to 120 
tapes and one or two built-in tape drives. The access times 
to select a tape are acceptable for a backup or library type 
application. 

Given the emerging network requirements, there is an even 
bigger need for a small device that fits the standard "o'/j-inch" 
peripheral slots. These are approximately 140 mm wide by 
83 mm high by 203 mm deep (5.75 in by 3.25 in by 8 in ). This 
is enough volume to hold a smaller peripheral-size tape 
drive and a changer mechanism. 

These smaller devices that perform unattended backup are 
typically called autoloaders. At HP's Computer Peripherals 
Bristol division, we investigated this growing need. This 
investigation led to the development of the HP C1553A 
DDS-2 digital audio tape autoloader. Fig. 1. 

The HP C1553A autoloader incorporates the HP C1533A 
DDS-2 tape drive described in the article on page (5. It holds 
six DDS-2 cartridges, each having a nativ e capacity of four 
gigabytes. With data compression, each cartridge can hold 
typically eight gigabytes, giving the autoloader the ability to 




Fig. 1. THe HP C1553A DDS-2 digilal audio tape autoloader contains 
a DDS-2 tape drive and n cartridge changing mechanism that Selects 
one of six cartridges from a magazine and loads it into the drive. 
Cartridges are clanged automatically under sortware control. 



back up typically 48 gigabytes without Operator interven- 
tion. Two Standalone versions are available: The HP 6400 
Model 48AL for IIP 9000 workstations and the HP SureStore- 
Tape 1200e for Novell Netware and Windows NT systems. 

Design Objectives 

The basic definition for the HP C1553A autoloader was very 
simple. It was to be a DDS tape autoloader, fit into a stan- 
dard o'/j-inch peripheral enclosure, use a standard HP DDS 
drive with minimum (or no) modifications, use the drive's 
SCSI II interface, hold as many tapes as possible, and be 
reliable and ergonomic. 

During the investigation phase for this product there were 
prototypes of similar products available. To keep the invest- 
ment low we considered procuring one of these designs. 
However they fell shoil of some of the requirements, so the 
decision was made to produce our own design. 

Given the small size of the product and the desire to accom- 
modate as many tapes as possible, the interior space was at 
a premium. Despite frequent questioning by the engineers, 
the outside dimensions could not be increased if we were to 
be sure of satisfying the maximum number of customers. 
One possibility was to have a "power bulge" on the rear of 
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the unit, but this was rejected because it might obstruct 
some customers" installations. 

It was decided that the new HP C1533A DDS-2 tape drive 
was to be fitted inside the autoloader. For reasons of manu- 
facturing simplicity and cost, the drive had to Ik- used with 
minimum modification. We were also aware that the auto- 
loader would be a platform for future DDS drives, so easy 
integration was important for future generations as well 
The price of the autoloader could perhaps be only double 
that of the DDS-2 drive for several rimes the capacity. 

The SCSI II interface of the built-in drive can be used to 
pass on control commands to the changer mechanism. Thus 
the customer need only use one SCSI bus ID where some 
libraries require two. 

The more tapes the device can hold, the more attractive a 
product it will be. Competing autoloaders with four car- 
tridges were known to be under development, so our goal 
was to match this number or exceed it. 

We saw the magazine holding the tapes as a simple storage 
solution, thai is. inexpensive and capable of being stored 
like a \ideo tape. This allows the user to treat a magazine as 
a big single backup tape, rather than having to manipulate a 
lol of single lapes. 

For reliability and ease of use, use models and metrics were 
developed. In the early stages of development, user tests 
were conducted on possible design concepts. 

Physical Architecture 

The physical architecture is dominated by the lack of space. 
Filling the :i":-inch C1533A tape drive into the volume al- 
lowed for I he autoloader accounts for much of the difficulty. 
The drive is placed at the rear of the autoloader volume lie- 
cause ii has ils interface connections al the rear and the 
tape loading at the front. There is just enough space for a 
tape in front of the drive, but unfortunately no fronl-to-rear 
room for a mechanism. However, removing the front panel 
(bezel ) of the drive, which is not required, created a vital 
few extra millimeters. 

The construct ion of the front of the DDS-2 drive is such that 
the tape can overlap the drive when il is ejected, thai is. the 
tape can extend into Ihe drive about 1 1 mm. This means that 
a tape must be moved vertically above the drive to remove 
it; it cannot move down through the drive mechanism. Tliis 
allows just over 10 mm from the front of any tape to the 
autoloader front panel. This configuration also places the 
drive at the rear bottom of the autoloader so ihai access to 
other tapes is from above the drive. 

Tliis configuration does have some benefits. The drive con- 
nectors and option switches on the rear and bottom are di- 
rectly accessible al Ihe exterior of the autoloader. Thermally 
this is also the best arrangement because the drive base is 
exposed to the exterior air. The drive base is an important 
heal dissipation arcajusi below the main controller printed 
circuit assembly. Finally, for integration and repair we were 
able to design Ihe autoloader to accept the drive with a sim- 
ple bracket arrangement and a single connecting cable. 

The changer mechanism, c ontroller printed circuit assembly, 
magazine, and door and front panel pails have to lit in the 
rest of the available space. Al this point we checked again 



Autoloader Control Electronics 

The autoloader conf ot electronics were designed with the aim of linking the 
mechanism and firmware elements with tow-nsk. proven technology at low cost 
Tne mam controller printed circuit assembly is a through-hole design wilh a shape 
to suit the space available The space envelope for the pruned circuit assembly 
was derived directly Irom the mechanical CAD model because it was so tight 
Control of the mechanism is managed by a Hitachi HE/325 microcontroller with 
on-ooard une-time-programmable IOTP) and RAM memories, nearly 90% ot the 
pins being available for I/O. logic-level pulse width modulation signals generated 
by the miciocontroller control ihe dc motors and their integral gearboxes Two- 
level motor current sensing is used to detect mechanical iams or excessive motor 
loading The tour motors and the picker solenoid are powered from the '2V supply 
available in 5%-inch peripheral slots. 

The State of the mechanism is determined by optical means for each motion, a 
mechanical part has a rib that is made to pass through slotted optical switches 
The rib has slots at datum positions in the motion that are detected by the opto- 
switch The width of each slot is calculated to reflect the mechanical tolerance ot 
the particular motion so that the firmware can guarantee a particular mechanical 
position as long as the optical switch is open An important philosophy here was 
to position each slotted nb Icombl at the "point ol action" (the farthest point from 
ihe motor drivel so thai backlash does not compromise the accuracy ol ihe position 
detection 

By using relatively large (and inexpensive! motor drive ICs operating well within 
their thermal specifications and mounting the printed circuit assembly vertically for 
optimum convection cooling, thermal problems were avoided For the picking 
action, an oversized solenoid is operated conservatively so that it does not get loo 
hoi. The solenoid delivers a relatively large force for the picker fmgeis but for short 
durations I less than two seconds). 

The Iront-panel printed circuit assembly is connected to the mam controller 
printed circuit assembly by a flexible circuit Mounted on ihe front-panel printed 
Circuit assembly are the three front-panel switches, the door open optoswitch, 
three LEDs, and the LCD The LCD is a custom design procured with a standard 
driver IC on its flexible circuit, which is soldered lo the front-panel printed circuit 
assembly All ol these components were physically modeled in the HP ME30 CAD 
system to integrate ihe electrical and mechanical designs 

An important design goal was ease ol access to the printed circuit assembly since 
the firmware is stored in an OP device that must be replaced if firmware upgrades 
are necessary. To this end the board is fully connectorized and fixed by a single 
screw No ad|ustmenis or calibrations to the printed circuit assembly are needed, 
so complete primed circuit assemblies can be swapped in if necessary The layout 
of the primed circuit board is heavily influenced by the flexible circuit designs and 
a lot of lime in the early stages uf the project was spent on ihe topography of the 
flexible circuits, then routing, and the effect of the positions and direction of eniry 
on the punted circuit assembly layout In particular, to keep Ihe cost of the flexible 
circuits as low as possible they were all designed as single-sided circuits This 
dictated pin ordenng on ihe printed circuit assembly, which also needed lo have 
minimum layers to keep il low in cost The final primed circuit assembly has |ust 
tour layers including power and ground planes covering 90% of Ihe board area 
There are four flexible circuits connecting the motions and the Iront-panel printed 
circuit assembly Their physical layouts were modeled on the HP ME30 system and 
also using paper mock-ups lo check for control of then positions when moving, as 
well as track layout 

Greg K Trezise 
Development Engineer 
Compuiei Peripherals Bristol 



whether we could exceed ihe form (actor, and were again 
asked to look inward rather than outward. 

Ideas were tried in outline form to inaxinii/.e the number of 
cartridges with the simplest mechanism. Ii quickly became 
c lear that Ihe size of the DDS cartridge imposed limitations 
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that dictated the capacity and mechanism design. For exam- 
ple, even with minimal thicknesses in between, there is only 
room for three cartridges above the drive. To achieve a ca- 
pacity of four with a simpler mechanism the cartridges 
would have to move up and down in front of the drive, but 
this violated the form factor. 

Using only mockups and cartridges, we arrived at the possi- 
bility of rotating the column of three tapes above the drive. 
This accommodated six cartridges and would make us the 
market leader in capacity- There is just space, but how could 
it be implemented? The vertical height of the components 
had to be pared down to the minimum. For example, there is 
1.5 mm between cartridges, 1 mm for a shelf in the maga- 
zine, and 0.5 mm clearance ( all dimensions nominal). The 
volume swept by the six tapes rotating is very large, taking 
up about half the height of the autoloader and most of the 
width, leaving only about H mm on each side. We decided 
that the changer mechanism would have to occupy some of 
the swept volume when the tapes were not rotating. 

We used the HP ME30 mechanical CAI) software to plan our 
air space and implement the concept. At this point three 
mechanical engineers developed the design, sharing the 
same file system and conventions so that we could easily 
load the subassemblies of our colleagues to check for 
clashes and interfaces. 

Autoloader Design 

The autoloader can be broken into several physical sub- 
assemblies, as follows: 
Magazine 

Mechanism motions — X, Y, Z, R 
Front panel and user interface 
Control electronics and motors 
Mechanism firmware 

Drive firmware. SCSI interface, and link to the mechanism. 

Magazine. The magazine is made from polycarbonate plastic 
moldings (see Fig. 2). It is simply a container for the six 
cartridges, three on each end. The main molding is a box 
structure into which some shelves are fixed. 




Fig. 2. The six-cartridge magazine is designed to be handled like 
Wte large tape can ridge. 



The thin ( I mm ) wall sections and usability features made 
this an extremely challenging design. Required features 
were retention of the cartridges and acceptance of the cor- 
rect orientation only. In oilier words, you can only put the 
cartridges into the magazine iti the correct way, and then 
they slay in, even when you shake them by hand or apply 
shock and vibration to the unit. The cartridges were not 
designed with these features for autoloader use, so we had 
to be creative; In addition there are regulatory requirements 
(I 'L94-V2 flame resistance) and a need lor reasonable robust- 
ness, that is, the Cartridges should not be damaged if the 
magazine is dropped on the floor. The magazine also has 
areas for a label and indications to help ease of use. There is 
a gear form along one side for automatic loading. The maga- 
zine is shaped so that it can only be inserted the correct way 
into the autoloader. 

A semi transparent polypropylene library case is supplied 
with the magazine. This allows the user to store the maga- 
zine neatly with some protection. It is similar to the library 
cases for commercial videotapes. 

X Motion. Looking from the left side of the unit, the X motion 
moves horizontally (front to back) in the autoloader (see 
Fig. 3). This motion moves the cartridge horizontally. The 

(continued on page 161 




Ibl Panel 

Fig. 3. (a) Interior layout nf the HP CI 553A autoloader. (l'l Motions 
of the cartridge changing mechanism. 
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Autoloader Firmware Design 



When the HP C 1 553A 00S-2 autoloader was Designed, one of the primary goals 
was to add the autoloader mechanism to a standard DOS dnve with no hardware 
modifications to the drive and minimum firmwafe modifications The 'esulting 
architecture allows the autoloader mechanism to pe independent of rjrrve hardware 
and to be used with different drive products 

Onginally. HP's DOS lape drive product line was not designed to be used with an 
autoloader However the requirement (or a low-cost autoloads' mechanism was 
realized and steps were taken to add an autoloader to the current product line 
This required three basic steps 

• Design of the drive/autoloader interface, both hardware and soltware. requiting 
no hardware changes to the drive 

• Addition of the loader command set to the drive firmware 

• Design of the autoloader electronics and firmware to enable the required 
communications with the drive 

Drive/Autoloader Interface 

Since the drive had not been designed with the intention of interfacing to an 
autoloader, there was very little hardware available to create an interface to the 
autoloader mechanism It was decided that a port that was used for debugging 
purposes in manufacturing test could be used to communicate with the autoloader, 
since it had no use outside the manufacturing line. 

The port has four data lines and a single address line along with the required 
handshake lines for the drive's 68000 processor This allows a total of four regis- 
ters, two write-only and two read-only It was decided that these should be 8-bn 
registers accessed by two successive 4-bit operations The four registers are the 
drive status register, the autoloader status register, the drive autoloader command 
register, and the autoloader drive report register 

Two registers are used as a command report mechanism to allow the drive to send 
commands to the autoloader This is the basis for the control of the autoloader 
When the drive receives an SCSI command that requires autoloader operation, il 
writes the appropriate single-byte command code into the drive autoloader com- 
mand register as two four-bit writes When the autoloader has completed the opera- 
tion it places the single-byte report in the autoloader drive report register and 
asserts an interrupt signal 10 the drive to indicate that the register should be read 



Commands that require parameters are preceded bv a push parameter command 
Trw is a sino^-byte command tr^ All other commands nave the 

top bit cleai This allows the remaining seven bits to be pushed onto a parameter 
stack Successive push parameter commands allow more than seven bits to be 

The autoloader status and dme status registers are used for handling the front 
panel Since the autoloader s front panel is completely different from the stand 



panel switches are read and interpreted by the drive via the autoloader status 
register This allows maximum flexibility of operation and configuration 

To maximize the usability of the autoloader, n was decided to use a character- 
based LCD display to give messages to the operator Since most of the status 
information comes from the drive, the drive status register is used to pass status 
codes to the autoloader to display status messages on the display The text for the 
messages is stored in the autoloader processor ROM While it would have been 
more flexible to store the messages in the drive, there was insufficient space 

Drive Firmware Architecture 

The changes required to the drive firmware to implement the drive/autoloader 
interface relate to two distinct areas The architecture of the firmware for the 
autoloader is shown m Fig 1 

First, the normal front-panel handling task within the firmware is replaced by a 
new version, which communicates drive status to the autoloader This receives 
status information from both the SCSI task and the drive task on the drive. This 
status information is passed over the drive/autoloader interface rather than being 
displayed on the drive front panel The SCSI task is changed to read the buttons 
on the new front panel as well as the eject button on the drive The drive eject 
button is left active so that a tape can still be recovered from a drive in an auto- 
loader even if the autoloader hardware is not working 

Secondly, the SCSI task required the addition of the functionality to handle the 
SCSI medium changer command set. This involved adding new functionality to the 
task to interpret a new class of commands and pass them on to the autoloader 
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mechanism Parsing ihe commands on the drive allows the drive to remain In 
control of the whole autoloader and minimizes the risk of conflicting commands 
going to the drive and autoloader H also avoids duplicating the software to parse 
SCSI commands for both the drive and the autoloader 

Autoloader Firmware Architecture 

The autoloader firmware consists of three distinct functions These are communi- 
cating over the interface to the drive, handling the display, and controlling the 
autoloader mechanism 

These three functions are implemented in three separate tasks running in a round- 
robin fashion with a 1-ms time slice for each function This made development of 
the software easier and allowed the separate functions to be implemented with 
minimal risk of interference with one another. 

To save hardware costs, the drive/autoloader interface registers are not imple- 
mented as hardware latches. Instead, the I/O lines from the drive are wired directly 
into the ports of the H8/325 microcontroller used to control the autoloader mecha- 
nism The H8 has a set of internal memory locations that mirror the imaginary 
hardware registers. When the select line from the 68000 is asserted, indicating an 
access to the drive/autoloader interface registers, this causes an interrupt to the 
H8. The H8 reads its I/O lines and handshakes the data to or from the 68000 This 
gives the appearance to the 68000 of slow hardware latches. The tasks running on 
the H8 merely need to access the internal memory locations as if they were the 
registers 

The drive status register is treated slightly differently from the other registers in 
the drive/autoloader interface Because the drive can send repeated status values 
to this register faster than the display task on the H8 can read them, the values 
are queued within the H8 to beYead in sequence. This ensures that an important 
status code is not lost behind a less important one. In addition, certain status 
codes cause flags to be set within the H8 that determine whether the drive is in a 
certain state This allows tracking of the state of the drive. 

Mark Simms 
Development Engineer 
Computer Peripherals Bristol 



cartridge is gripped by metal fingers (mounted on a picker 
ami ) on an edge near where a human grips the cartridge. 
The fingers are sprung shut . gripping a cartridge in ease of a 
power failure, and are opened hy a solenoid. The fingers are 
mounted on an ami. which pushes and pulls the cartridge. 
The ami can pull a cartridge out of the magazine and push il 
into the drive. The picker ami is moved by a belt, which is 
driven by a dc gear motor. 

The cartridge is not designed for manipulation by a mecha- 
nism, so the choice of features that were suitable for grip- 
ping and aligiunent was limited. The obvious edges were not 
specified in the cartridge standard, and it took two years to 
have some of these features added to the standard. 

Y Motion. The V motion moves the cartridge and picker ami 
up and down. The picker ami is mounted on a platform that 
is lifted or lowered by two cams. The picker arm runs on 
a shaft, allowing the X motion. The shaft and the other X- 
motion parts including (lie gear motor and belt are all 
mounted on the platform. Connections are made to these 
parts by a flexible circuit. The platform has three puis, one 
on the left and two on the right, which project out the sides 
(looking from the front of the unit ) into cants, one on each 
side of the unit. The puis run in tracks that resemble escala- 
tor shapes, that is. they have 50-degree slopes with horizontal 
I m h i ii ins. The pins can only move vertically because they also 
run in slots in metal plates. The cams with the shaped slots 




View ol V Cams from Front Top Righl 




View ol V Cams Irom Front Top Left 

Fig. 4. Y-tnotion cam design, (a) View of the V cams from the front 
top righl. (1>) View of the Y cams from the front top left, 

move backwards and forwards and drive the pins and the 
platform up and down (see Fig. 4). Both cams are driven by 
one dc gear motor. The one on Ihe right has a molded tack 
and is driven directly by a gear on the gear motor. The left 
cam is connected by a lever across the bottom front of the 
unit to Ihe right cam, and is driven by the same Y gear 
motor. This cam arrangement tolerates inaccurate position- 
ing of the Y gear motor and cams. The height of the cam 
components themselves determines the height accuracy of 
the platform, which early calculations showed is adequate. 
The pins can be anywhere on the horizontal portions of the 
cam tracks, which are about 5-mm long. The flal plate ar- 
rangement of Ihe cams and tracks fits neatly into the unit on 
either side of the platform. The left cam extends into the 
magazine rotation area making extra use of the space when 
the magazine is not rotating. 

R Motion. The R motion is the rotation of the magazine. This is 
achieved by a large disk in the top of the unit. The magazine 
sits on lop of the drive. The usual chive lid (top) is replaced 
with one that has the front edge cut away to allow the car- 
tridge to be lifted straight up with the 1 1-nim overlap. The 
rotating disk in the top of the unit has two moldings attached 
to il that hang down on either side of Ihe magazine, allowing 
it to be located and turned around. Originally Ihe rotating 
disk in the top of the unit was going to be inside the unit. 
However, because of Ihe extreme vertical space problems, 
the disk is actually part of the exterior surface of the unit. 
The disk rotates 180 degrees and Ls driven by a dc gear motor 
through a clutch. The dutch allows the disk lo be driven into 
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ail end stop for ac curacy while preventing damage to the 
gear motor, which was found in early prototypes. The clutch 
is a custom design and drives a gear form on Uie disk. 

Z Motion. The Z motion is the movement of the magazine in 
and out of the autoloader. The magazine has a large rack 
(gear form) on one side. This engages with a gear in the unit, 
which is driven, through a custom clutch, by the Z dc gear 
motor. A microswitch (Z switch ) activated by a rocker arm 
iiniii ates when a magazine has been inserted by the user. 
The insert and eject mechanism ( Z motion ) is deliberately 
designed to mimic the familiar home \ideo recorder type of 
action. User tests showed that this action was familiar and 
intuitive. The action of the user is to push the magazine into 
the autoloader through the door, which is sprung shut. The Z 
switch detects the magazine and the Z gear motor starts. 
When the magazine is pushed a little farther the gear engages 
and pulls the magazine from the user. On entry 'he magazine 
compresses a spring-loaded pusher arm, which is used on 
ejection. The Z switch also detects when the magazine has 
reached the fully home position, that is. fully into the unit. On 
ejection the Z gear motor pushes the magazine out through 
the opened door. As the gear disengages, the sprung pusher 
completes the ejection. The magazine is caught by a small 
sprung plastic part to ensure a consistent eject distance. The 
distance is over 22 mm, which allows handicapped users to 
grip and remove the magazine. 

The lid assembly, which contains the R and Z motions, was 
one of the later subassemblies designed and proved very 
difficult tu finalize. The physical space restrictions and the 
desire lo gel the right feel for the user meant that several 
iterations of design had to be prototyped and tested. 

Front Panel. The front panel assembly provides the controls 
(three buttons), displays, and door (see Fig. 5). A printed 
circuit board mounted behind the front-panel plastic mold- 
ing has the display and switch components on it. Once again 
space Was at premium and the whole assembly had lo be 
thin to miss other mechanism pads. The layout was deter- 
mined by the user tests and the position of the door. The 
door is central in the upper portion. The entry has a keying 
feature so that the magazine cannot be inserted the wrong 
way. Combined with the magazine features, this means that 
the user is guided inlo correctly inserting the cartridges and 
prevented From making mistakes. This means that the cor- 
rect orientation of the cartridge is ensured when it arrives 
inside the autoloader. This is not always the case in other 
autoloader systems, which have to check the orientation. 

The door opens inwards and is Sprung shut, but for maga- 
zine ejection the door must be opened by the unit to allow 
the magazine to eject. The door is locked when a magazine 
is inside the unit to prevent tampering or injury to the user. 
It is unlocked when there is no magazine inside to allow the 
user to insert one. The door is pushed open and locked by 
the movement of the left-hand cam. The cam travels are 
extended to allow this operation, At the normal resting V 
height (bottom of travel in front of the tape drive), the cams 
move farther to unlock the door, then farther to push open 
the door. This allows the extra function with no extra gear 
motor or mechanism. An optoswitch sensor detects whether 
the door is open; its main purpose is for safety, so that the 
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Fig. 5. Front panel layout 

unit can be stopped in case of a faulty lock. In this case, the 
unit will display an error message, "Close Door," and wait. 

The appearance and position of the front-panel displays and 
controls were determined by the industrial designer within 
the mechanical design Limitations and were heavily influ- 
enced by the user test results. Early on, some ntockxips were 
tested because there is potentially a lot of information that 
could be displayed lo the user, such as error messages and 
many status messages, about lid total. The most basic button 
and the one thai all users require is the Eject button. This 
was made large and obvious, the shape making it look push- 
able so that minimum or no text is needed for users to 
choose it. The second button selects a starting tape, of the 
ones loaded, and the final button starts a manual backup. 
Alternatively, the unit can be controlled by SCSI commands 
from the host computer. 

The displays are grouped into two types: those giving overall 
slalus that can be seen from a distance, such as idle, backing 
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Network Backup with the HP C1553A DDS Autoloader 



The four main applications tor the HP C1553A autoloader described in the 
accompanying article are: 

• Single large backup 

• Centralized network backup 

• Fully automated backup 

• Near-line data storage. 

The backup of a large amount of data in a single session is a clear application for 
the autoloader Today there are many servers with a disk capacity exceeding that 
of a single DOS-2 cartridge, which is typically 8 gigabytes with 21 data compres- 
sion. The system administrator with a single tape drive must either manually 
insert new tapes into the drive when doing full backups, or must settle for incre- 
mental backups that only back up the data that has changed since the last lull 
backup. These two options present some difficulties Backups are typically carried 
out at night when server use is lower, so tape changing is inconvenient at best. A 
restore based on an incremental backup routine can be complicated since it will 
involve using several unrelated tapes The autoloader, with its six cartridges, 
enables the system administrator to protect up to 48 gigabytes of data in one 
single unattended session 

Mosl of todays local area networks consist of several servers and many clients. 
Centralized network backup involves backing up all servers and clients across the 
network onto one high-capacity drive such as the autoloader This is a cheaper 
alternative to having a separate tape drive on each server. Other benefits include 
having only one tape drive and one software package to administer and enhance 
security by having all removable data in one location, which can be physically 
secured This is the same rationale that has been employed for centralizing net- 
work printing on one high-duty-cycle printer For additional flexibility each of the 
the autoloader's six cartridges can be configured to hold data from a specific 
source. For example, each server can be backed up to its own cartridge and all 
clients to one of the othei cartridges. Alternatively, all servers and clients on a 
segment of the network can be backed up to a specific cartridge. The exact choice 
will depend on restore and disaster recovery considerations 



Fully automated backup relieves the busy system administrator from another task 
previously taken for granted in the days of central mainframes tape rotation. 
Methods such as "grandfather-father-son" and "tower of Hanoi" were developed 
to prevent overuse and wearout of media and to make available several differently 
aged versions of data when restoring. These methods involve backing up to a 
different cartridge every day For the system administrator with a single tape drive 
this means manually changing the tape in the drive every day If for some reason 
this does not happen most software packages will abort the backup, meaning that 
the system is unprotected. More significant, when the time comes for a restore, 
the system administrator must be on hand to retrieve the correct cartridge from 
secure storage and manually load it into the drive These tasks can now be auto- 
mated by making use of the autoloader's multiple-cartridge capacity A simple 
routine with five data cartridges and a cleaning cartridge could be configured to 
perform a full backup every weekday to a new tape. This weekly cycle could be 
lepeated over an extended period of time A routine giving a longer file history 
would involve performing a full backup on the first day of the week, followed by 
daily incremental backups to the same tape The magazine would then provide 
five weeks of protection for a server of up to five gigabytes Using a tower of 
Hanoi rotation scheme, sixteen weeks of protection can be achieved with a single 
magazine In all cases, the only manual intervention would be periodic magazine 
rotation to a fireproof safe or offsite location. Restores no longer need to involve 
the system administrator, either. With all of the cartridges available by random 
access in the magazine, the backup software can give users the ability to restore 
their own files with overall access rights controlled by the system administrator 

Prolonged operation of tape drives without any tape head cleaning can result in a 
media warning that causes the backup software to abort the backup. This need 
not be the case with the DOS-2 drive, which has a has a self-diagnostic capability 
that senses the write error rate When this increases beyond a conservative 
threshold, the drive sends a message to the backup software, which can respond 
with the initiation of a head cleaning cycle using the cleaning cartridge included in 
the magazine. This will typically occur every twenty-five hours of use and ensures 
a long period of error-free operation without system administrator intervention 



up, or fault condition, and those giving further detailed infor- 
mation that is required when the user is near the unit, such as 
"Insert Mag" or "Clean Me." A custom LCD was selected for 
the detailed information, the custom icons and layout en- 
abling a lot of information to be conveyed at a glance with- 
out long texl messages. Ten characters of text are available 
to display messages (see Fig. 6). The printed icons beside 
the three buttons and three LEDs were also developed and 
tested for intuitive use by users and to avoid any text that 
would require localization. The exception to this is thai the 
word "Eject" was required by the English speakers tested 
because the universal eject icon, seen on almost every VCR 
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Fig. 6. Liquid crystal display layout 



and cassette player, was not recognized! The word "Eject" is 
acceptable internationally. 

Control Electronics. This development effort is described in 
"Autoloader Control Electronics" on page 13. 

Mechanism and Drive Firmware. This development effort is 
described in "Autoloader Firmware Design" on page 15. 

Mechanical Design Methods 

ME30, HP's 3D computer-aided design tool, was used by the 
mechanical and manufacturing engineers. It was nin on HP 
9000 Series 700 workstations thai had a common disk 
mounted with directories Structured and named like the 
product subassemblies. The designers were responsible for 
maintaining the latest revision of their pans in these shared 
areas, and for providing a macro that would simply load all 
the subassembly parts. The motors, the flexible circuits, and 
the main components on the controller printed circuit as- 
sembly were all modeled. Thus the latest design was avail- 
able to the designers for cross-checking, and to the procure- 
ment and manufacturing engineers for process planning. HP 
ME30 proved very valuable at speeding up the checking and 
success of prototype assembly builds. Better visualization 
allowed the designers to spot problems early, thereby avoid- 
ing embarrassing problems on prototype builds. On one oc- 
casion, we discovered that we were about to design a gear 
motor assembly tlirough the center of the 118 microprocessor! 
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Near-line data swage is an evolving application for multiple storage oevices 
based on using intelligeni data management software known as Hierarchical 
Storage Management software The size of hard disk mass storage on servers is 
increasing all the time Today's average network server has a disk capacity of 3 
gigabytes and this is ejected to use to 40 gigabytes within the next five years 
The system administrator faces a constant challenge to ensure economic and 
efficient use of disk space by use's The reason tor not adding hard disk drive 
capacry at will is cost Hard disks are a very expensive data storage medium, but 
are necessary to ensure fast access to data, access time is of the order of 10 
milliseconds Magnetic tape by contrast, has a cost per megabyte of data one- 
hundredth that of hard disks, but the access time of a tape ritrve is on the order of 
30 seconds An analysis of the use pattern of files on a typical server shows that 
some current files are accessed frequently, but that the majority are older files 
used infrequently Hierarchical Storage Management software tracks file access 
and automatically migrates infrequently used files to a lower-cosi storage me- 
dium Although the file is stored on another device, a phantom file of zero size is 
left m the original directory As far as the user is concerned the file is still present 
When access is required the Hierarchical Storage Management software retrieves 
it automatically The small delay in retrieving the file from the slower device is 
acceptable on an occasional basis All of the activity is transparenl to the users, 
who effectively see a virtually unlimited amouni of disk space The data migration 
is triggered at typically 80% of disk capacity. The system administrator therefore 
never needs to be concerned about running out of disk space The autoloader with 
its six cartridges can provide up to 48 gigabytes of near-line data storage at a 
fraction of the equivalent hard disk storage cost 

Performance Considerations 

The autoloader's large capacity is well-matched by the DDS-2 dnve's high data 
transfer rate However, backup is a resource intensive operation that uses all of 
the components of (tie computer and netwoik. not iust the tape drive Careful 
selection of all of the hardware is required to balance the throughput and ensure 
that there are no bottlenecks The exact configuration will depend on the type of 
backup being performed 

For server-based backup, the limiting component is typically the hard disk drive 
Backup involves randomly accessing all files on the hard disk The disk can spend 



more time seeking data than actually reading it The limitation can be reduced by 
"scanning" the data to be read over several disks While one or more disks are 
seeking data one of the other disks can be reading data. This spanning can usually 
be implemented m the operating system but is more commonly implemented in 
liardware m the form of a redundant array of inexpensive disks (known as a RAID 
dak atrayl Here a dedicated controller card takes care of all the data input and 
output for all of the disks anrj frees tne operating system from that overhead In 
most cases an HP CI 533A DOS-2 tape dnve back ing up data trom a RAID disk array 
with five disks will approach its maximum native transfer 'ate of 510 kilobytes per 
secono which is sguivaien' to 60 megabytes per minute with data compression 

for centralized netowk backup, the limiting component is typically the network 
Today's most popular network topology is Ethernet, operating at a bandwidth of 10 
megabits per second During backup all the data must travel across the network, 
along with all of the disk access commands This results m most cases in a transfer 
rate of about half of the maximum the DDS-2 drive can achieve This can be reduced 
further if the amount of traffic on the network is high enough to result in packet 
collisions, so backups should be run at night when traffic is low To achieve higher 
fransfer rates over the network, faster topologies must be used FDDI over fiber- 
optic cable and 100 Base-VG both operate at 100 megabits per second, ten times 
faster than Ethernet Implementation of these technologies is becoming more 
widespread for reasons other than backup, such as multimedia and video. For 
existing installations it is not necessary to recable the entire network The maionty 
of data transferred will be from server to server, so these can be connected together 
with a dedicated high-speed backbone This will result in a backup speed close to 
the DDS-2 drive's maximum. 

When using intelligent data management software, an apparent increase in per- 
formance can be seen. This is because the infrequently accessed files, after hav- 
ing been backed up several limes, are considered stable and are no longer backed 
up A full backup therefore involves fewer files and can be completed in a shorter 
time This performance gain is achieved with software without any changes to the 
hardware 

Michael G. Beriagne 
Technical Marketing Engineer 
Mass Storage Europe 



Although valuable, the latest UP mechanical GAD software 
does nol fully simulate all the mechanical motions. In litis 
respect it is less mature than EE CAD. So (he traditional 
design, build, (est, redesign cycle is slill (he major way to 
achieve reliability improvements in the design. Anything 
dial can be done to shorten this cycle, rapid prototyping (or 
example, can save weeks or months of lime (o market . The 
models allowed us In use Ihe lalesl fasl prod Hyping meth- 
ods), including stereo lithography and CNC milling of parts. 

Design Margin Analysis 

Because of (he desire to prove as much of Ihe design as pos- 
sible before commitment to tooling, we adopted an unusual 
approach to the mechanical tolerances. Typically designers 
will approach key areas and perform a tolerance analysis. 
They will add up ihe tolerances for the pails using data thai 
they hope is representative of the production parts. Because 
of Ihe lack of space, inierdependency of all the subassem- 
blies, and simply pressure of work on (he designers, we de- 
cided to adopt another approach. A consultant from (ranlield 
Institute of Technology, one of t he leading teaching and con- 
sullancv groups in matiufacluriiig technology in Ihe I K. was 
enlisted in help analyze the tolerances. We started from the 
ouisidc in, deciding on ihe key areas of fuiictionalily. then 
building up spreadsheets of ihe systems with ihe tolerances. 
Our procurement engineers provided capability study data 
for ihe manufacturing processes of similar parts. 



Starling out with simple arithmetic, we built (his analysis 
into a design margin index. 1 The managers and designers 
were (hen able to have a single number for (he "goodness" 
of the design in each of six key areas. This was Obtained by 
the rooi-sum-of-scniures ( RSS) method of calculating toler- 
ances.- The squares of the tolerances are all added, and then 
the square rool of (he sum giv es (he variance of Ihe assem- 
bly. If we had simply laken worsi-case tolerances the design 
would nol have worked because Ihe worst-case numbers 
were too large. The HSS method assumes that Ihe pails have 
a typical Gaussian distribution of sizes. Statistically, taking 
(he RSS only excludes 0,27% of (he possible cases. This was 
nol considered completely satisfactory, so our goal was (o 
have 1.5 limes Ihe RSS figure as ihe minimum design crite- 
rion for each key area. A simple scoring Kiel hod of compar- 
ing Ihe actual RSS figure for ihe key area with Ihe goal "I 
1.5RSS gave us (he "goodness" figure. Because the key areas 
are not independent, this allowed us to view (he overall ca- 
pability of Ihe design and prevented conflicts such as im- 
provements by a designer in one area increasing margin al 
(he expense of another key area. 

The use of a consultant to check the design and the use of 
Ihe design margin index strengthened our execution of (he 
mechanical design, forcing us to change the design and 
production processes of some parts. 
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A Change of Direction 

As liie design approached complelion and we were ready to 
atatt production prototypes in maiiufacuiring. the division 
reassessed the manufacturing strategy. Il was clear that the 
product would c onsume more resources lhan the division 
was willing to commit. The increase in volumes of the 
DDS-l products and the launch of the DDS-2 drive at nearly 
the same time would cause a bulge in resource requirements. 
The decision was made to find a partner to manufacture the 
autoloader mechanism, while HI' supplied the DDS-2 drive. 

Biiro-und DatcuTechuik (BUT) GmBH was selected and 
from November 1092 worked closely with us to take the 
autoloader into manufacturing. BDT was selected for their 
manufacturing expertise and quality in producing similar 
products, including paper sheet feeders for printers and 
another autoloader. The partnership has proved extremely 
successful. Their engineers have looked critically al the de- 
sign and improv ed it. They have developed it and taken it 
successfully into manufacturing HP was able lo redeploy 
people on oilier projects, leaving only a core learn lo work 
with BDT. 

Applications 

To ensure the availability of soli ware solutions that fully 
support the automation features of the HI' C1553A, HP has 
developed I he LABS (Low- Admin Backup for Servers) stitn- 
dard guidelines for software developers. The LABS guidelines 
define a set of software attributes that virtually eliminate 
human operator involvement in the backup process. The 
IIP SureStoreTape 1200e producl is available as a bundle 
with LABS software developed by Palindrome Corporation. 
In addition, several other solutions are available for differ- 
enl operating systems, such as Cheyenne ARCSERYE and 
Palindrome Backup Director for Novell networks. Arcada 
Backup Exec- for Windows NT, and Legato Net Worker for 
I "NIX " systems and Novell. 

The autoloader can work in two ways, depending on the 
application software: random mode or sequential mode. In 
random mode the software issues SCSI medium changer 
commands to load a specific can ridge number. The software 
therefore has complete control over the operation. In se- 
quential mode the user starts the backup from Ihe chosen 



cartridge, say cartridge 1, and the host writes until the tape 
is full. The host then issues an SCSI unload Command anil 
Ihe autoloader replaces Ihe cartridge With the nexl one auto- 
matically. This allows easier integration into older syslems 
thai do not support the SCSI medium changer command sel. 

See page 18 for more aboul network backup applications. 
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Automatic State Table Generation 



The HP C1553A DDS tape autoloader requires a complex sequence of 
simple operations to carry out mechanical retries. These sequences are 
defined in tables Cadre's Teamwork was used for input and an automatic 
tool was used to generate the tables to go in ROM. 

In Mark J. Simnis 



The autoloader firmware for the HP G1553A digital audio 
tape autoloader was written in the C programming language 
to run on a Hitachi H8/325 processor. This processor is an 
embedded system microcontroller with built in ROM. BAM, 
I/O ports, timers, and serial ports. This allows a very low- 
cost implementation of the autochanger controller in which 
most of the functions can be carried QUI in a single chip. 
However, the largest ROM size available on the H8 series of 
processors was 32K bytes. This means that the complex 
retry algorithms required for controlling such a mechanical 
device needed to be implemented in as compact a manner 
as possible. 

Our laboratory has a large amount of experience in producing 
table-<lriven systems. All of our products have had some form 
of table-driven control structures in some pan of their linn- 
ware. However, experience had shown that there can be 
severe problems maintaining table-driven code because of 
Ihe difficulty of maintaining 'he tables. This derives from the 
lack of readability of software written in C or assembly lan- 
guage that merely defines the contents of data structin-es. A 
lot of documentation needs to lie added to the source code 
lo explain the meaning of the entries. If this is not main- 
tained, then the declarations rapidly become unreadable. 
This greatly increases both the lime needed to implement 
changes and the risk of errors. 

The designers of the IIP 9145A cartridge tape drive and the 
HP 35170A DDS tape drive attempted to improve this situa- 
tion by defining state machine languages that can be trans- 
lated into (' source code automatically, These languages 
offered powerful Constructs for defining Ihe tables in lei ins 
of state machines. The software would remain in one stale 
until an event was detected. Then a set of actions would be 
carried out and a new state entered. This approach made the 
table definition much more readable than the basic data 
declarations and greatly allev iated the maintenance problems. 
However, the state machine languages suffered front many 
of Ihe problems thai are characteristic of "unstructured" 
programming techniques. There was no observable How in 
Ihe source code since transitions were permitted between 
any two states. This made it very difficult to follow the flow 
of ihe program and determine whal sequence of actions had 
occurred. 

To aid in documenting these State machines, Ihe Teamwork 
structured analysis tool from Cadre Technologies was 
adopted This allowed the Initial problem analysis to be car- 
ried out graphically. A slate transition diagram was produced 



to document the desired solution (see Fig. lj. This was then 
implemented using the state machine language. However, as 
the state machine language description was modified, the 
diagram gradually became more and more out of date and 
was updated periodically. This meant thai while the diagram 
could be used to gain an initial familiarity with the software, 
it could never be guaranteed to be completely accurate. 

With the HPCT553A autoloader, these problems became 
more serious. The slate tables were 10 be used very exten- 
sively for mechanical control. Also, there was a very strong 
need to communicate die control algorithms to mechanical 
engineers and the product test team. This required that good 
accurate documentation be available to all within Ihe divi- 
sion. It was felt that any manual system for maintaining such 
documentation would prove unusable in real situations. As a 
result, a decision was made to generate the state tables di- 
rectly from the Teamwork diagrams. This would ensure 
that, the diagrams were always accurate reflections of the 
software. 

Design Implications 

Analysis of Ihe IIP ( T,V>:jA motor control software showed 
thai the software divides into two major sections. The first 
is a number of routines I hat handle Ihe low-level control of 
the mechanism. These routines control Ihe motors and sole- 
noids, read sensors, and track Ihe position of the mecha- 
nism. They Hack control Information and map that onto the 
Control signals required lo operate the motors in Ihe correct 
direction at the correct power level. They denounce input 
readings and map them into mechanism position information. 
These routines are Implemented in ( ' and use global variables 
to interface with the rest of the software. The routines are 
called in sequence to carry out all Ihe necessary interfacing 

to ihe mechanism. 

The second section is the control sequencing. Thus contains 
a number of state machines. Some of these are directly 
linked to Ihe individual mechanism parts. Others sequence 
individual mechanism operations together in response to a 
single command. These suite machines interface with the 
lOW-leyel routines by means of the control information and 
mechanism position global variables 

Since several state machines are running concurrently with 
the low-level routines, this concurrency must be reflect ed in 
the soli ware. Kach stale machine, when called, checks to 
see if a transition needs to be made. If not. control is returned 
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1 idle 



mc.aclion="mc lammed*' I 

mc action="mc failed"/ 

mc aclion="mc retract picker" 



motor_action="molor. action _power on"/ 

mc statU5="no. error". 

mc map statusOrue", 

mc map. cartridge hoight="talse - 

mc action="mc power on_Z"" 



mc aclion="mc |ammed" I 

mc_ action="mc railed"/ 

mc aclion=~mc redact picker" 



(mc_action="rnc lammed " I 

mc action="mc failed"! & mc door_open/ 

mc_action="mc. retract picker" 



l 

D 
D 



recovering Z position 



mc_ actions "mc _ success"/ 
, mc action="mc power on Y" 



closing door 



mc aciion="mc success"/ 
mc actions "mc retract, picker" 



recovering X position 



mc action="mc success 



13 wailing (or drive 



mc action="mc jammed"! 

mc_aclion="mc_lailed7 

mc_ action="mc retract picker" 



retracting cartridge 



mc action="mc_|ammed"l 

mc..action="mc_ failed"/ 

mc action="mc fetract picker' 



motor, drive .status valid & 

((motor drive status lurking= "false" & 

motor drive status _prosent="fafse") I 
Imotor _ dnve_status lurking-'true" & 

motor drive status presenl="lrue")|/ 
mc_aclion="mc recover cartridge" 



mc actionV'mc success" 



recovering cartridge 



mc actiom="mc success" 



mc_X_motion cartridge. present="tnie" & 
motor drive status present="true"/ 
motor drive status lurking="truc" & 
mc action="mc put cartridge" 



mc aclion="mc jammed'l 
mc action="mc_ failed"/ 
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16 checking cartridge 



14 putting cartridge back 



mc. X_ motion, cartridge present? "true" 
motor drive status lurking="false" & 
motor drive status prosent="false7 
mc_action="mc plaHorm to drive" 



mc X motion cartridge present="false" & 
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1 )mc X motion cartridge presenl="lalse" & 
motor__drive._status_lurking="true" & 
motor drive status presenl="tnie7 
mc_action="mc_plariorm_lo_drive" 



mc aclion="mc success" Si 
motor. drivo_stalus_lurking="(alse/ 
mc action="mc unload cartridge" . 



mc action="mc success" & 
/motor drive status lurking="true" 



IB recover cartridge at drive 



2 J mc _aclion="mc_success" & 

mc cartridge height="mc 25 height"/ 
mc cartridge heighl="mc_ 14 height"; 
mc_action="mc platform to cartridge" 



mc action="mc_jammcd"l 

mc_action="mc. failed"/ 

mc action="mc retract picker" 



(mc_action= mc . success I 

mc aclion=~mc failed" I 

mc. aclion="mc jammed") & 

mc X motion cartridge present="false' 
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mc_ action="mc power on R" 
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1 (mc.actioni"mc_ success" I 
mc_action="mc .failed" I 
mc action="mc jammed") & 
(mc_R_motion_at end="false" l 
mc X motion cartridge present="true 7 
mc status: "no error" 
mc map status="true"; 
mc cartridgc_side="mc_456_5ide"; 
mc action="mc rotate magazine" 
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mc cartridge height="mc_36 height". 

mc_action="me_pIatform to cartridge" 



10 going up to push 



mc_aclion="mc jammed"! 
mc action="mc failed"/ 
mc_action="mc . retract picker" 
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motor action="motor status jammed 



mc_ action= "mc jammed"! 

mc action="mc failed"/ 
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mc action="mc failed - / 
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Fig. 1. Stale IraiisiUuii diagram. 
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immediately. If a transition is needed, that transition is exe- 
cuted and control is returned. This ensures that all the state 
machines and low-level routines can be called in sequence, 
thereby niaintaining the required concurrency. 

From tliis analysis, the following design criteria were derived 

for the state machine implementation: 

The state machines must be able to respond to the values 

of mechanism position variables and execute transitions 

accordingly. 

The state machines must be able to set mechanism control 
variables when a transition occurs. 

A timeout mechanism is required that can handle times up 
to 30 s with a resolution of 1 ms. 

Each state machine must execute at most one transition 
when executed. 

Each transition must be executed as a complete unit to 
lessen t he risk of data contention problems. 
The state machine implementation must use the minimum 
space possible. 

The ability to store a history of trace information must be 
provided for debugging purposes. 

Interpreting Teamwork/RT 

The Teamwork/RT product provides a graphical state 
machine editor that has the following features: 
There is a set of states, each of which has a unique number 
and a unique name. 

There is an initial state, indicated by a single initial transition. 
Transitions out of states may enter other states or may 
indicate that the state machine has exited. 
Transition information indicates the condition under which 
the transition occurs and may give actions that are to be 
carried out on that transition. 

Each transition condition is a logical expression consisting 
of a number of comparisons of variables with values. 
Each transition action is an assignment of a value to a 
variable. 

The full syntax of this stale machine description is sup- 
ported by the code generator tools. This gives a fairly rich 
design environment in which to work. It has the additional 
advantage that if the diagram is correct according to the 
Teamwork syntax checker, it should generate code correctly 
and that code should compile. 

To parse the stale machine diagrams, a program was written 
to access the Teamwork database. This retrieves the data 
structures for a Complete diagram, parses them, and gener- 
ates the required code table. The program connects to the 
Teamwork database, retrieves the state transition diagram, 
and follows the linked list of states. For each slate, it identi- 
fies each transition that exits that slate. For each transition, 
it parses the associated text and generates the required data 
Structures for its condition, actions, and next slate. 

Finding the stall and end slates of a transition and finding 
Hie transition information that is bound to a given transition 
involves the concept of an instance number. Each item in a 
Teamwork diagram is given a number to identify it This 
number is unique across all items in the given diagram, 
whether an item is a text block, a transition, or a state. 

The Instance numbers of the initial and final stales and the 
text block associated with a given transition are stored in 



that transition's entry in the linked list of transitions. The 
state can be identified by searching through the linked list of 
states to find the one with the same instance number as in 
the transition entry. The text block holding the transition 
information can be identified by searching through the linked 
list of text blocks to find the one with the same instance 
number. 

To increase the performance of the code generator, an array 
of pointers to text blocks and stales is set up at the start of 
the program. The list of text blocks is searched and the 
entry in the array indexed by the instance number of a given 
block of text is set to point at that block of text. The list of 
states is searched and the entry in the array indexed by the 
instance number of a given state is set to point to that state's 
entry. This allows the start state, end state, and text block 
associated with a given transition to be found by a single 
table look-up each. 

Parsing Transition Information 

The transition information associated with a transition con- 
sists of an event or an event, a / character, and a semicolon- 
separated list of actions. 

The event is a logical expression consisting of a number of 
comparisons. Comparisons are linked with logical OR opera- 
tions indicated by the I character and logical AND operations 
indicated by the & character. The logical NOT operator, indi- 
cated by the - character, can be used to invert an expres- 
sion or comparison. Order of execution can be indicated by 
the use of parentheses. Each comparison consists of either 
just a variable or a variable, a comparator symbol, and a 
constant value in double quotation marks. The comparators 
can be equal =, greater than >, less than <, not equal ~=, less 
than or equal to <=. or greater than or equal to >=. 

Each action consists of the name of a variable, an equals 
sign =. and the value to be assigned to that variable in double 
quotation marks. 

This gives a text block of the form: 

mc_timed_out I 
( mcjam_sense & 

mc_picker_state="mc_pickcr open" 1/ 
mc_X_motion_direction="rnc_X_brake"; 
mc_action="mc jammed" 

This should be read as follows: If mc_timed_out is true, or both 
mc_jam_sense is true and mc_picker_state is mc_picker_open. then 
set mc_X_motion_direction to the constant value mc_X_brake and 
set mc_action to the constant value mc Jammed and transition 
to the next state. 

This lext is parsed using a parser written using the yacc and 
lex tools provided with the HP-UX* operating system, this 
generates a reverse Polish form for the logical expression 
along with Ihe values required for I lit- actions. 

Generating the State Table 

The major issue with Ihe slate table design was to implement 
the lull syntax Supplied by the Teamwork/RT slate transition 
diagrams in as compact a form as possible. Performance 
was nol an issue. The maximum response lime required of 
the firmware was of the order of ,'J ms. This was easily 
achievable with the designs chosen. 
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To produce a machine readable form of the transition 
information, each part is taken in I urn. 

To reference variables, the IIS processor uses 16-bit address- 
ing. This can be truncated to 10 bits to limit the address space 
to the 1024 bytes of RAM available on the processor. Since 
there are over :!()()() references to less than 50 variables, an 
index table is far more efficient. In the transition information, 
a six-bit index value is stored. This is used to look up the 
address of the variable in an array of pointers. 

Since every variable in the logical expression is associated 
with a comparator, it would be useful to store the informa- 
tion indicating the comparator in the spare two bits with the 
variable index. Unfortunately, there are six comparators, 
which would require at least three bits to store. However, 
the comparators form pairs of inv erses. Fqual is the oppo- 
site of not equal, greater than is the opposite of less than or 
equal to and less than is the opposite of greater than or 
equal to. As such, the logical NOT operation is used so that 
only the three basic comparators have to be used in the 
state table, allowing the comparator to fit in the two spare 
bits of the variable index. Since most comparisons are 
equalities, diis saves a great deal of space while preserving 
the simple table format with no items crossing byte bound- 
aries. All comparisons are with S-bit values. These are 
stored in the byte after the variable index and operator. 

The logical operators are stored in single-byte values. Tltis is 
wasteful since only a couple of bits are really required for 
these. However, it maintains the simplicity of the generator 
and interpreter by avoiding the necessity of table items 
crossing byte boundaries. 

The expression is stored in the table in reverse Polish format 
with the comparisons as values. The expression is terminated 
with a zero byte to indicate where calculation should slop. 

Each action consists of the six-bit index for the variable 
stored in one byte and the singie-byte value to be assigned 
stored in the next byte. The list of actions is terminated by a 
zero value to indicate the end of the list. 

While most of the actions involve assignments of a single 
byte, the setting up of timeouts requires that a 16-bit value 
for the timeout in milliseconds be set. This variable is con- 
sidered a special case by the state machine generator and 
two assignments are generated. This maintains the readabil- 
ity of the state machine diagram without adding complexity 
to the state machine table to handle 16-bit values. 

The final part of the transition information is the next state. 
This is given as a single-byte value. 

The state table entries for the transition text example given 
earlier are: 

( mc_.tirned_out_index 1 128 I, ],/• = '/ 

I mc Jam_sense_index 1 128 1, 1,/* == */ 

I mc_picker_state_index 128 I. mc_picker_open, /" == 7 

1, /* AND*/ 

2, /* OR V 
0. 

mc_X_motion_directionJndex, mc_X_brake, 

mc_action_index. mcjammed. 

0, 

0. 



The transition data for each slate is generated in turn. At the 
end of the transitions out of a given state, a single byte of 
value 255 is inserted to indicate the end of the transitions 
associated with that state. 

To access the transitions associated with a given state, a 
table of pointers is used. The pointer indexed by a given 
state number points to the first transition from that state. 

A single byle of data is used to hold the number of the 
current state. This is the same value as appears on the 
Teamwork/RT diagram. 

Finally, a structure is generated that holds a pointer to the 
state pointer table, a pointer to the index variable, a pointer 
to the state variable, and a code to be used for logging. 

The complete data structures for the state table are shown 
in Fig. 2. 

State Table Interpreter 

To execute the state table an interpreter routine is used. This 
reads the state table and carries out the actions required. 

The Interpreter routine is passed a pointer to the header 
structure for the state machine to be executed. It uses the 
pointer to the state variable to get the current state. It uses 
this as ah index into the state pointer table to get a pointer 
to the transitions for the current state. It then scans the 
transition information. 

The first thing in the transition information must be an ex- 
pression, terminated by a zero byte. The Interpreter routine 
checks each byte in turn to see if it is a comparison, an 
operation, or the terminating zero. 

If either or both of the top bits are set. then it is a compari- 
son and the next byte is the value to be compared. The bot- 
tom six bits of the byte are used as an index into the index 
table to get the pointer to the variable to be checked. This is 
then used to gel the variable's value. The first two bits are 
used to determine whether the comparison should be for 
equality, greater than, or less than. The next byte is read, the 
comparison is executed, and the result is placed on a stack. 
The current byte is then incremented past both bytes of the 
comparison. 

If neither of the top two bits is set but the value is not zero, 
then the byte indicates a logical operator. If the operator is 
AND or OR. then the top two values are removed from the 
stack, the operation is carried out on them, and the result is 
pushed back on the slack. If the operator is NOT. then the top 
value is pulled off the stack, inverted, and pushed back on. 
The current byte is then incremented past the operator. 

This is repealed until a zero byte is found as the current 
byte. Then the top value is pulled off the stack to indicate 
whether the expression evaluated to TRUE or not. 

If the expression is TRUE, the actions are read in turn as byte 
pairs until a zero byte is found as the first byte. For each 
byte pair, the value in the second byte is assigned to the vari- 
able pointed to by the pointer in the index table indicated by 
the index in the first byte. When the terminating zero byte is 
found, the next byte is assigned to the state variable and the 
interpreter routine exits, having completed a transition. 
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Fig. 2. State table data structures. 



If the expression evaluates to FALSE, the actions are skipped 
over until a zero index is found. The next byte is skipped as 
well, since litis is the next state value. The subsequent byte 
is checked to see if there are any more I ransitions to pro- 
cess. If this byte is not 255, then another transition follows 
and it is processed in the saine manner. If this byte is 255, 
then all the transitions have been processed and none have 
conditions that are TRUE. The interpreter routine exits with- 
out carrying out any actions or altering the state variable. 

Initialization and Exception Conditions 

The state variable must be initialized at startup for the initial 
state of the system. Rather than provide a mechanism for 
the initialization routines to know the initial state, an addi- 
tional state 0 is added to the state machine. Any transitions 
on the diagram that connect off-page are viewed as connect- 
ing to this additional state. Since the initial transition that 
identifies the initial state is the only one that can come from 
off-page, this ;dlows the initial state to be set merely by set- 
ting it to zero. As soon as the state machine is executed, it 
will transition into the initial stale on the diagram. 

When an exception occurs, it is useful lo be able to restart 
the state machine to initialize those areas of the mechanism 
under its control. Rather than conned all the transitions that 
handle exception conditions lo the initial stale. Ihese are 
allowed to nin off-page. In the Teamwork/RT notation, this 
means that the state machine has exited and that it should be 
restarted from the initial state on iis next invocation. Since 
these off-page connectors connect to the additional state 0. 



this has exactly the desired effect. The exception transition 
can then be made to restart the state machine without Ihe 
clutter of unnecessary connections on the diagram. 

Debugging and Trace Logging 

To be able lo debug problems with a real-time control system, 
it is important to be able to gel trace information back from 
ihe unit after a failure to determine what Ihe system was 
doing at the time of failure. Willi a system that is largely im- 
plemented as state tables, it is possible to follow the How of 
actions in terms of the stale changes involved. As such, the 
state table interpreter was designed with a tracing function 
built in. 

Whenever a state change occurs, the stale table interpreter 
logs the current lime as a Ki-bil rolling clock counting in 
milliseconds. Ihe S-hit log value in Ihe slale table header 
Structure that identifies which state machine is being exe- 
cuted, and (he 8-bil value of the new state. The resultant 
32-bit value is stored in an internal rolling buffer and is also 
transmitted on one of the H8 processor's built-in serial lines. 

To decode Ihis trace information, host-based interpreter 
programs are used. These decode Ihe information in the 
trace log to identify exactly which stale table and state within 
the table are inv olved. These are then printed out using the 
names on the Teamwork/RT state transition diagrams. This 
enables the changes in stale lo be followed on the diagrams 
merely by following Ihe names given. The time each state 
was entered is listed alongside the name of Ihe state lo facil- 
itate ihe interpretation of the mechanical factors that may 
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have caused the stale change. The use of milliseconds 
throughout, both for timeouts and for trace logging, allows 
engineers debugging failures to work iti real-world values 
rather than units that are solely dependent on the software 
design. 

During product test, the serial output from the micropro- 
cessor is monitored and the data is interpreted in real time. 
This allows both real-time debugging of failures and the 
gathering of a complete history of a lest. In the field, the 



rolling buffer is returned from the autochanger via its SCSI 
interface. This only allows a recent history to be returned, 
but does not require additional hardware to monitor the 
serial port. 

HP-UX is based on anil is compatible with Novell's UNIX" opecaung system It also complies 
with X/OpenV XPG4, POSIX 1003 1. 1003.2 FIPS 151-1. am) SWD2 interlace specifications 

UNIX is a registered trademark m ihe United Stales and other countries, licensed exclusively 
through X/Qpen Company Limited. 

X/Open is a trademark ol X/Qpen Company Limited in the UK and other countries. 
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Using State Machines as a Design 
and Coding Tool 



The wide acceptance of real-time extensions to structured analysis 
techniques have led to the use of state machine descriptions for the 
specification of systems in which state or sequence is a vital part. 
However, the techniques for implementing these specifications have 
remained poorly understood and haphazard, leading to implementations 
that are difficult to verify against the specification. This paper examines 
different approaches to the use of state machines and explores their 
advantages and disadvantages. 

by Mark J. Simms 



In I he theory of state machines, two types of state machine 
model are defined: the Mealy Model and the Moore model. 
In the Mealy model, outputs are associated with transitions. 
When a transition happens, the output is generated. The for- 
mat of this type (if state machine as implemented in Cadre's 
Teamwork software is shown in Fig. L In the Moore model, 
outputs are associated with states. When a state is entered, 
the output is generated. The formal of this type of state 
machine as implemented in Teamwork is shown in Fig. 2. 

Traditionally. Ihe Mealy state machine model hits been used 
for software systems. Teamwork versions prior to 4.0 did 
nut support the Moore state machine model. This is because 
software state-based systems typically only take action in 
response to an event. An output is set on Ihe transition, al- 
though it may remain set indefinitely. This is sometimes not 



the optimum way of approaching a state-based model, but 
tends to reflect the way software engineers think. 

As a result, tliis paper will concentrate on the Mealy model 
and references to state machines may be laken to assume 
litis model unless there is a specific reference lo Ihe contrary. 
All of the concepts can be applied to Moore-model state 
machines because any Moore state mac hine can be imple- 
mented as a Mealy State machine, although the converse is 
not true. 

When Ihe original concepts of structured analysis were pro- 
posed by Tom DeMarco. 1 no c oncepts of state or sequence 
were used. This led lo difficulty in modeling a large class of 
problems, including real-time control systems thai are largely 
based around slale and sequence and have little data flow 
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content. As a result, two proposals were made for extensions 
to the structured analysis notation that would enable this 
type of problem to be modeled. 

The rust proposal came from Paul Ward and Steve .Mellor.- 
who Introduced a concept of signals to the structured analy- 
sis notation. Signals differ front data flows in that they carry 
timing information but no data. There are two types of sig- 
nals: events and prompts. Events are generated by state 
machines and by data transformations in response to 
changes in the environment and cause state transitions 
within the state machine. Prompts are generated by state 
machines to control data transformations. Ward and Mellor 



proposed tlvree types of control that could be exercised on 
data transformations: enable, disable, and trigger. Teamwork/ 
SIM adds the kill prompt. The format of a Ward-Mellor state 
machine is shown in Fig. 3. 

The second proposal came from Derek Ilatley and Imtiaz 
Rrbhai,* who use the concept of a control flow. Cont rol 
flows have the same properties as data flows, but are used 
lor control purposes. They carry data and are continuously 
valid. The only way to pass timing information is to change 
the value of a control flow in response to an external event. 
Logical expressions involving input control flow values are 
used to determine when transitions of a state machine take 




Engine Running/ 
Trigger "Reset_Cruise" 



Resume/ 

Enable "Accelerate_to_Desired_Speed" 



1 






Resume/ 

Enable "Accelerate_to_Oesired_Speed" 



Start Increasing^Spced/ 
Enable "Accelerate" 



Stop Increasing Speed/ 
Disable "Accelerate_to_Oesired Speed" 
Enable "Maintain Speed_Reached" 



Accelerating 



Activate/ 

Trigger "Get Speed" 




Start lncreasing_Speed/ 
Enable "Accelerate" 



StartJncreasing^Speed/ 
Enable "Accelerate" 



Step Increasing Speed/ 
Disable "Accelerate" 
Enable "Maintain Speed Reached" 



Brake Engaged/ 
Disable 
"Maintain^ 
Speed. Reached" 



Activate/ 
Trigger "Get. Speed" 




Brake Engaged 



Fig. 3. Ward-Mellor state inaclune. 
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Engine Running; 7:ut 
Action='Reset Cruise 



Command: Resume*/ 
Action* Accelerate to Destred Speed 



Command; Slart Increasing, Speed - / 
AcIion="Accelerate" 





Acceleraling 



Commands "Activate 7 
Action="Get_Speed 




Command="StailJncreasing_ Speed" 
Actions'Accelerate" 




Command="Resume7 
Actions'Accelerate to_Desired Speed" 



Command="Stop Increasing Speed'. 
Desired Speed Reached: True 
Action=~Maintain_Speed Reached" 



Command="StartJncreasing Speed"/ 
Actions'Accelerate" 



Commands' Stop Increasing, Speed"/ 
Actions" Maintain Speed _ Reached" 



Brake _Engaged=*True~/ 
Actions Disable 



Commands" Activate"/ 
Actions Gel .Speed ' 




Brake Engageds True"/ 
Actions Disable" 



Fig. 4. H;il !•■> F'irlilmi Mat* machine 

place. Assignments are used in a state machine to control 
the values of output control flows. The format of a Hatley- 
Pirlihai state machine is shown in Fig. 4. 

Ward and Mellor's signals can only be used in a Mealy state 
machine since they have an instantaneous quality and ii 
makes little sense to have an instantaneous signal associ- 
ated with a stale. This could he interpreted as the signal 
being sent whenever (he slate is entered, but this IS really 
associating it with all the transitions into the state. 

Hat ley and Pirbhai's control flows can be used with either 
state machine model. If the selling of control flows is associ- 
ated with transitions in a Mealy state machine, they are as- 
sumed to be set until actively reset on another transition. If 
I he setting of control flows is associated with slates in a 
Moore state machine, then the control How is deemed to be 
undefined if the state machine is in a stale ibat does not 
actively output thai control flow. This leads In a clearer defi- 
nition of what is happening with a Mealy state machine and 
therefore a tendency to use this model. 

Design Criteria 

W hen using stale machines as a design tool rather than an 
analysis tool, the method of implementing the state machine 
must be considered to give the design a rigid definition. In 
particular, the means of passing the external inputs to the 
slate machine and the way the stale machine interfaces to the 
procedural How of the resl of the code must be well-defined. 

Ward and Mellor recommend thai the analysis be partitioned 
into tasks according to the number of state machines in the 
system. In addition to the state machine, lite data trans- 
formations that it prompts and the event recognizers that 
supply il with events may be in the same task. This leads to 
a very simple interface to the rest of the code. The stale ma- 
chine is the lop-level module of the lask. Il calls an event 
recognizer to get an event from the outside world. The even! 
recognizer returns an even! to the siale machine if one is 
available or returns a code indicating no even! if no event is 



available. The state machine then executes the transition 
by llagging data transformations as enabled, disabled, or 
triggered and changing to the next state. It executes any 
enabled or triggered data transformations by calling the 
relevant procedures. Finally, it sets the state of triggered 
data transformations to disabled before calling the event 
recognizer again. 

This implementation approach has a few drawbacks. First, if 
there are a large number of slate machines, then the number 
of tasks can become very large. For systems that have to be 
implemented on hardware willt limited power, this can be 
very wasteful. To gel around ibis problem, a system by which 
multiple state machines can be implemented in a single lask 
is required. This can be done by making the stale machine 
return control to the calling procedure after each loop. This 
allows multiple slate machines to be called in sequence, 
This also allows other data transformation modules to be 
called in the same sequence, imitating the parallel nature of 
the analysis. 

Secondly, in systems thai are capable of suspending lasks. 
the Ward-Mellor approach is very wasteful of processor 
time. In this type of system, the event passing mechanism 
should be huill into the operating system in such a manner 
that tasks can block until an event is generated. This works 
well if diggers are the only prompts required. If data trans- 
fortnalions mtisl be enabled and disabled, the operating sys- 
tem must be used to do this. However, this might produce 
excessive operating system overhead. 

The most efficient implementations based on this type of 
design require that only triggers be used, but multiple stale 
machines can be executed in the same task. With these re- 
strictions, the Ward-Mellor design approach can be highly 
• Hirieni for large and medium-sized systems. A real-time 
operating system handles the scheduling of the lasks and 
can block a task waiting for a semaphore lo be set. The 
semaphore can be set either by another lask or by an inlet 
nip! service routine responding to an external event. A 
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counting semaphore can be used to allow multiple events to 
activate a single task. Alternatively, a message queue mecha- 
nism ran be used to implement a similar technique. If events 
are passed between state machines in the same task, t hen 
this can be implemented by flags that are checked by the 
event recognizer before suspending. 

The top-level module in each task is responsible for calling 
the event recognizer routine. This blocks until the task's 
semaphore is set. It then determines what event occurred 
and returns the corresponding event code to the lop-level 
module. The appropriate state machine is called based on 
the event code and passed the code as a parameter. The 
state machine determines the data transformation modules 
to be triggered and executes them in turn. It assigns the new 
stale and returns. The event recognizer is then called again. 

Hatley and Pirbhai offer far less guidance than Ward and 
Mellor on how to convert structured analysis state machines 
into designs. However, the meaning of the state machine 
appears more obvious at first sight, leading to a fairly 
Obvious design. 

Since the control flows are simple data values, these are 
easily implemented as static variables. The state machine 
needs only to read the variables, evaluate the logical expres- 
sions on the transitions in sequence until one is found to be 
true, execute the assignments on that transition and assign 
the new state. This continues with the transitions from the 
new state. 

This approach has I wo problems. First, the order in which 
the transitions are processed is arbitrary. This means that 
the actions performed by the implementation are not neces- 
sarily uniquely determined by the state machine description. 
This is, however, a problem with the underlying analysis 
method. It is the responsibility of the analyst to ensure 
either that no two transitions become active simultaneously 
or that the system will operate within specification even if 
they do. 

Second and more serious, the slate machine offers no 
obvious way of interacting with the environment other than 
through the static variables. Tins means that the state ma- 
chine would ideally run in its own task interfacing with the 
rest of the system via the variables representing the control 
flows. Tlus is a highly inefficient implementation. This can 
be improved by implementing the state machine in such a 
manner that it returns control to the module that called it 
after each cycle. This allows several state niaclune modules 
and associated data transformation modules to be placed in 
the same task. This improves efficiency somewhat, but still 
uses processing time when nothing is being done. 

Because of the inefficiency of this sort of implementation it 
can only be used where there is sufficient processor time to 
spare. However, it does have advantages when there is no 
operating system or where the operating system only offers 
basic functionality. Since the state machine operates on 
global variables, some simple data transformations can be 
incorporated into the state machines. This can produce a 
design that is very easy to learn and to follow and that can 
be implemented very easily. 

It is sometimes advantageous to add some of the features 
of eontrol-flow-based state machines to signal-based state 



machines. This involves adding states that control the flow 
of the state machine based on the value of variables. There 
should always be at least one exit transition active when- 
ever such a state is entered. These states are not true states 
since die state machine never waits in the state. Instead 
they are merely decision points that affect the future flow 
through the state machine. Under certain circumstances, 
Ihis can greatly simplify the state machine. 

Implementation Techniques 

There are two major approaches to implementing state 
machines in software. The first is to generate inline code 
that executes the state machine logic directly. This is the 
faster solution, but uses a large amount of code space. This 
approach is typically used on large systems where there is a 
lot of memory and on systems where response time is very 
important. 

The second approach is to generate a table that encodes the 
state machine logic in a compact manlier that is then inter- 
preted by a separate state machine interpreter. This produces 
very compact code that is suitable for systems where code 
space is low and response time is not critical. 

Both signal-driven and conlrol-flow-driven state machines 
can be implemented eidier as inline code or as tables. Vari- 
ous different coding schemes can be used depending on the 
complexity of the syntax used for the state machine, hi sys- 
tems where the stale machine module never returns, the 
program counter can be used to determine the stale. More 
usually, however, a static state variable is used to maintain 
the state between calls of the state machine module. 

For a Hatley-I'irbhai type state machine, Ihis leads to an 
implementation of the form shown in Fig. 5. The state ma- 
chine is implemented as a single C function. A static variable 
within the function holds the state. This variable is initial- 
ized to the initial state of the state machine when the task is 
stalled. The function is structured as a switch statement in 
which each case limb is the processing for a given state. The 

void state_machine( void ) 

I 

stalic stale = Engine Off: 
switch I slate ) { 
case Engine_Ott: 

if (Engine Running = True )( 

Action = Reset Cruise 

state = Idle; 

I 

break: 
case Idle: 

if I Command = Resume II 

Action = Accelerate to Desired Speed: 

stale = resuming: 
} else il ( Command == Slart_lncreasing_Speed 1 1 

Action ■ Accelerate; 

stale = accelerating; 
) else it ( Command = Activate ) { 

Action = Gel Speed. 

state = Initialize; 

} 

break; 
case ( Slowing }: 



break; 

} 

I 

Fig. 5. 1 lode for Hatley-Pirbhai Slate machine, 
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sdefine number of enabled .functions 3 
(define Accelerate. to Desired Speed INDEX 0 
•define Accelerare INDEX 1 
sdefine Maintain Speed Reached INDEX 2 

void I 'function .arrayHK number.of.enabled functions ) = 
( accelerate to desired speed, 
accelerate. 

maintain speed reached 

1: 

mi enabled array, number ol enabled functions! 
■ ! FALSE. FALSE. FALSE i 

void state machine! int event » 

< 

static int state = Engine Off; 

Ml 

switch i state ) ( 
case Engine. Off. 

if I event Engine Running 1 1 
Reset. Cruised; 
state = Idle; 

) 

break, 
case Idle: 

if ( event = Resume H 
enabled array! 

Accelerate to Desired Speed INDEX 1 = 
TRUE, 
state = Accelerating; 
} else if ( event = Start. Increasing Speed I { 
enabled array! Accelerate INDEX I = TRUE, 
state = Accelerating; 
t else if I event = Activate ) { 
Get Speed!); 
state ■ Initialize; 

} 

break; 
case Slowing: 



break; 

) 

lor ( i = 0; i < number of enabled functions; It* 1 1 
if! enabled array! > 1 )( 
lunction array! i 1(1; 



the array. At the end of the function, the array of flags is 
searched and the corresponding functions are called via the 
pointers in the second array. 

This design makes a few assumptions about the calling envi- 
ronment. First, the event recognizer functionality is not in 
the state machine itself. The event recognizer is executed in 
the calling environment and the event code is passed as a 
parameter to the function Secondly, the calling environment 
must not block because this would prevent the enabled 
modules from being executed. Since the enabled modules 
are called as functions from the state machine, the state 
machine function must be executed at least as often as the 
enabled modules need to be called. 

Since the content of these state machines is fairly simple 
and w-ell-defined, machine code Is a somewhat inefficient 
way of storing it. As a result, in systems where code space is 
at a premium, it may be advantageous to implement the de- 
scription of the state machine as a table lhat is interpreted 
by a separate routine. The following paragraphs describe 
one possible way of doing this for a Hatley-Pirbhai state 
machine. 

The state machine consists of an array of pointers and a 
state variable. The state variable is used as an index into the 
array to get the address of an array of structures containing 
a pointer and a value. Each transition consists of a single 
condition structure followed by a series of action structures 
and then a structure with a null pointer and the destination 
state indicating the end of the transition. The end of the 
transitions for a given state is indicated by another structure 
wiili a null pointer. This is depicted in Fig. 7. 

To execute litis stale machine, an interpreter lunction is 
given the state variable and the list of pointers. I 'sing the 
stale variable as an index into the table, it uses the corre- 
sponding pointer to find the first structure corresponding to 
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case limb corresponding (0 the currently active state is exe- 
cuted when the function is called. This tests the exit condi- 
tions for I he state in a series of if statements. If one of these 
is qualified, then the actions are carried out in the statements 
attached i<> the if statement and the new state is assigned. 
The ftutCtidll is ihen exited to allow other processing to be 
carried out in the same task. 

Fora Ward-Mellor type state machine, this approach leads 
to an implementation of the form given in Fig. 0. Two arrays 
are used. The first holds pointers to all the functions that are 
enabled and disabled, The second holds a flag indicating 
whether the function is currently enabled or disabled. The 
function lhat implements the stale machine has many simi- 
larities to that for the Hatley-Pirbhai state machine. It is 
structured as a switch Statement with a case limb for each 
state. Each case limb consists of if statements thai deter- 
mine if the corresponding actions should be executed. The 
conditions used are far more restrictive than in the Hatley- 
Pirbhai case. They check whether the even! code passed lo 
the function as a parameter is the value corresponding to 
the required event. The actions are either triggers, which 
simply call the function that corresponds to the required 
action, or enables and disables, which set and clear flags in 



Engine OH 



Idle 




Engine Running 


True 


Action 


Reset. Cruise 


NULL 


Idle 


NULL 


0 


Command 


Resume 


Action 


Accelerate to Desired Speed 


NULL 


Resuming 


Command 


Start Increasing Speed 


Action 


Accelerate 


NULL 


Accelerating 


Command 


Aclivale 


Action 


Gel Speed 


NULL 


Initialize 


NULL 


0 




1 


NULL 
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Fig. 7. State tables fur a table-driven state ntacWhe, 
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a transition from the current stale. It then checks to see if 
the condition is true hy comparing the variable pointed to by 
the pointer with the value stored in the structure. If they are 
different, the table is scanned until a structure with a null 
pointer is found Indicating the raid of that transition. The 
procedure is Ihen repeated until either a true condition is 
found Or a condition with a null pointer is found. If a condi- 
tion with a null pointer is found, all the conditions have been 
tested and the Interpreter function returns lo its calling 
environment. 

If a condition is found lo be true, the interpreter function 
scans the subsequent structures and assigns each value in 
Ihe Structure to the variable indicated by the corresponding 
pointer. Il continues lo do I his until a Structure with a null 
pointer is encountered, indicating Ihe end of Ihe transition. 
It assigns the value in this structure lo the stale variable 
to cause a change of stale. II then returns to its calling 
environment. 

A similar approach can be used for Ward-.Mellor slate ma- 
chines. Event codes and pointers to functions lo be enabled 
or disabled are encoded in the tables. This requires a slightly 
more flexible table format, but the principles are the same. 

Automatic Generat ion 

Once a rigorous mapping has been defined between Ihe 
slale machine design and the code to be produced from it, il 
is theoretically possible to design tools that can translate 
state machine (descriptions direclly to the source code for 
the final software. Willi the extensive use of grapliical state 
machine editors for analysis, this gives the potential for a 
graphical form of source code thai is easy to follow and easy 
to modify, removing some of the major problems of software 
mainlenance. 

Analysis tools are not designed with direct code generation 
in nuhd As a result, the mappings from stale machine de- 
scription to code must be defined hy the engineers on the 
project using the tools. This allows a lot of flexibility for 
experienced engineers to produce mappings thai are highly 
tuned to Ihe application concerned. Il does mean that there 
is a requirement for anyone wishing to loam about the code 
to determine what the mapping is and why il was chosen. 
Once this Ls understood, ihe Functionality of ihe code can be 
followed from the state machine diagrams. 

For a structured analysis tool to be able to fulfill tin's role, it 
must have a number of feat ures. The following are some of 
the most important: 

The tool must support the stale machine features required 
by ihe implenienters. This includes Mealy and Moore state 
machines, types of conditions thai cause transitions, types 
of actions that can be placed on transitions or in states, size 
and complexity of diagrams, and so on. 
It must be possible to integrate the tool into the configura- 
tion management system. Since the stale machine diagrams 
are now source code, it is vital thai they be treated with a 
high degree of care and attention. 

The tool must be able to access the diagrams. If the data is 
stored in any sort of database system, the appropriate access 
routines must be supplied. 

The tool must keep diagrams in a documented formal thai 
does not change between revisions. Continually modifying 



code generation programs to track the formal of the 
diagrams is unacceptable. 

Once these features have been established, code generation 
becomes a simple task of defining the mapping between the 
state machines and the code and Ihen designing the transla- 
tor program and any interpreter routines for table-driven 
State machines. The rest of the code can then be designed 
from Ihe remainder of the Structured analysis with the stale 
machine implementation in mind. 

There have been a number of dedicated code generator pro- 
grams on the market for some time, many of which use state 
machines as part or all of their input tools. These systems 
come wit h rigorously defined semant ics for I heir diagrams 
so that users of the system can rapidly understand designs 
with Which they are unfamiliar. These programs also come 
with a defined mapping of the diagrams to code. 

The biggest problem with this sort of system is that the fea- 
tures of the state machines and the mapping to code supplied 
by the vendor may not be ideal for Ihe implementation that 
is required for a given problem. Pew systems current ly avail- 
able offer any ways of tuning Ihe implementation for a given 
set of design criteria. This is one of the major features lo 
look for in such a system. 

A hybrid approach is possible in which a code generator tool 
is used, hut a custom front end is included to tune the result- 
ing code from the generator. This might be done either by 
H ealing the tool in the same way as a generic structured 
analysis lool and accessing the diagrams and generating 
code direclly from them or by postprocessing the resultant 
code to optimize it for ihe given situation. 

The hybrid approach is probably harder than designing a 
generator for a generic structured analysis lool. bin the re- 
sults could be better. The added rigor of code generators 
means that it is easier to use standardized semantics for Ihe 
system. The semantics are more likely to be complete than 
those of a structured analysis tool. 

Summary 

The usefulness of stale machines for specifying control 
applications has been well-proven. Their use in design and 
implementation is also showing a great deal of promise. It 
has shown major advantages in the following areas: 

• Rapid code implementation because of ihe very close 
mapping of analysis, design, and code 

• Ease of maintenance because of the av ailabilily of casy- 
to-read code in the form of state machine diagrams 

• Compact implementation of a large proportion of the 
functionality of a problem because of the use of table-based 
state machines. 

These advantages make the investment in lools for t his 
technique well wonh the effort and expense involved. 
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An Event-Based, Retargetable 
Debugger 

Remote and event-based debugging capability, a sophisticated graphical 
user interface, and adaptability to different languages and target 
platforms are some of the features provided in this debugger. 

by Arun K. Iyengar. Thaddeus S. Grzesik. Valerie J. Ho-Gibson, TVaey A. Hoover, and John R. Vasta 



Software developers rely heavily on debuggers for both 
fixing bugs and analyzing programs. The information ob- 
tained by a debugger can be used to add new features and 
improve performance. Event-based debugging 1 is a powerful 
method for examining program behavior. In event-based 
debugging, the user instructs (tie debugger to respond to 
events thai occur during program execution. The proper 
selection of events allows programs to be debugged at a 
higher level than would otherwise be possible. 

This article describes the HP Distributed Debugging Environ- 
ment ( HP DDE).- HP DDE is distributed because it is capable 
of debugging programs executing on remote hosts. HP DDE 
has been ported anil retargeted to several platforms and can 
be used to debug programs written in C. C++, FORTRAN. 
Pascal, and various assembly languages. The platforms thai 
HP DDE can run on include the HP-CX* operating system. 
Domain/( >S fi8K. DomainA >S Prism, the SPARC implementa- 
tion or Solaris, and the PA-RE3C implementation ofthe osF/1 

operating system. HP DDE has a sophislicaled graphical 
user interface thai provides the user With poinl-and-click 
access to commands and program state. Finally. HP DDE 
has many features thai support event-based debugging and 
debugging Optimized code. 

The modular architecture of HP DDE enhances its portability 
and has been a critical component in its success. IIP DDE 
consists of a main debugger thai communicates with several 
mi idiiles called mti lingers. The main debugger contains sup- 
port for generalized debugger functions, and the managers 
COntakl dependencies Oil specific languages, object code for- 
mats, large! platforms, and user interfaces. 

User- Visible Features 

Em- nt -Based Debugging in IIP DDE 

Almost all debuggers support a traditional debugging para- 
digm in which the user inserts breakpoints before critical 
points in Ihe program and examines the state of the program 
after breakpoints are hit to find program errors. The disad- 
vantage of this paradigm is lhal the user has to know where 
to insert breakpoints within the program. The user may also 
have In examine the slate of Ihe program al a number or 
breakpoints before obtaining the desired information 



In event-based debugging, the debugger does not return 
control to Ihe user until an event defined by the user occurs. 
By choosing an appropriate event, the user can avoid stop- 
ping the program at points that are not critical. Event-based 
debugging allows the user to identify what is going on in a 
program without spending large amounts of time inserting 
breakpoints at crucial points, 

Event-based debugging is achieved by monitoring the exe- 
cuting program at an interval or granularity level specified 
by the user. Whenever the debugger determines that a de- 
sired event has occurred, the debugger returns control to 
the user. A lower level of granularity, corresponding to fre- 
quent monitoring, allows the user to determine more accu- 
rately ihe location where a particular event occurs. How- 
ever, a low granularity level can cause execution time to 
increase substantially. HP DDE provides several intervals 
for monitoring program execution, including every machine 
Instruction; every source statement, and entry in or exit 
from each procedure. Monitoring can be restricted lo spe- 
cific procedures within a program. Typically, a user would 
use proceduie-entry-and-cxil-lcvcl granularity to narrow an 
event lo a specific procedure. After the faulty procedure is 
located, the user can use source-statement -level or machine- 
instruction-leve) granularity within the procedure to deter- 
mine Ihe exact local ion of an event. 

IIP DDE contains many features for event-based debugging 
including conditional breakpoints, execution traces, data 
walchpoinis. and event intercepts. Conditional breakpoints 
allow the user to halt execution at a given point in a pro- 
gram only if a set of conditions arc met. Execution traces 
suspend program execution al intervals specified by Ihe 
user. Data watchpoints allow the user to monitor a variable 
or memory range (program execution is suspended when a 
value corresponding lo a watched variable or memory range 
changes). Event intercepts allow Ihe user to regain control 
ofthe program when events such as program exceptions, 
shared library loading and unloading, thread creation and 
termination, and signals from Ihe operating system occur. 

The IIP DDE command language allows Ihe user lo declare 
variables for use in a debugging session and contains loops, 
conditionals, and assignment statements lo allow a wider 
range of event specification. 
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Examples 

Suppose llial the user desires to suspend execution every 
lime a variable x becomes zero. This can be accomplished 
with the following IIP DDE command:t 

dde> watchpoint x -do [if (x != 0) -then (go)] 

The behavior when no monitoring interval is specified in the 
watchpoint command (as in this example) is to monitor the 
expression after every source statement. 

As anot her example, suppose I he user wishes to break upon 
entry to function loo only if argument x is nonnegative. This 
can be accomplished using a conditional breakpoint: 

dde> breakpoint foo -do [if (x < 01 -then Igoll 

II is possible for the user lo examine data Structures while a 
program is suspended. The following IIP DDE commands 
will prinl all positive elements of a 20-element array A: 

dde> declare int dde_var 
dde> set dde_var=0 

dde> while dde_var < 20 -loop |il A[dde_varl > 0 -then \ 
(print A[dde_var]);\ 
set dde_var = dde_var t 1] 

The declare command allocates space for new variables lhal 
can be used in debugging sessions, and the backslash (\) indi- 
cates that an IIP DDE command continues on the next line. 

The following commands will suspend execution whenever 
the sum of the 20 elements of A is greater than 100: 

dde> declare int i 
dde> declare int sum 
dde> watchpoint A -do \ 

[set i=0; set sum = 0; \ 

while i< 20 -loop \ 
[set sum = sum + A(i]; set i = i + 1]; \ 

it sum <= 100 -then (goll 

Sequences of commands such as Ihese can be stored in a file 
and used as input to HP DDE. In addition, macro expansion 
allows a user to define a single command that is automati- 
cally expanded by the command interpreter into multiple 
commands. 

As a final example, the following commands will execute a 
program and print the number of limes a multithreaded 
application switches between different threads: 

dde> declare intts_count 
dde> set ts_count = 0 

dde> intercept thread_switch -do [setts_count = ts_count + 1; go] 
dde> go; print ts_count 

The User Interface 

Several user interfaces have been designed for HP DDE. The 
most sophisticated is a graphical user interface based on the 
X Window System and OSF/Molif. 3 It features multiple win- 
dows, context -sensitive pop-up menus, and online help. The 
user can customize menus, command but Ions, and key bind- 
ings. A typical HP DDE debugging session with four win- 
dows is illustrated in Fig. 1. The graphical user interface can 
manipulate up to six different types of windows: 
• Target program window. This is the window from w hich HP 
DDE is invoked. All data to and from the program being 

T HP DDE debugger commands can be entered in the command enlrv line area m the transcript 
display window described in the next section. 



debugged is directed to this window. The main parameter to 
I lie debugger is (he name of the program to be debugged. 

• Transcript display window. This is (he debugger's main 
window. It has four components. The command entry line 
componeni at (he bottom of (he window is for keyboard 
entry of debugger commands. All debugger commands can 
be entered from the keyboard in Ihis area. Above the com- 
mand entry line is the transcript area, which displays input 
lo the debugger (including commands accessed from the 
mouse) and debugger output. The bullous along the left side 
of this window provide quick access to common debugger 
commands. For example, the user can single-step the pro- 
gram (execute a single source Statement ) by clicking on the 
button labeled Step. These buttons can be reconfigured by 

I he user to represenl other commands. The pull-down menus 
across the top Of the transcript display window allow r access 
to all debugger commands via the mouse. 

• Source code display window. This window displays the 
source code for the program being debugged. 

• Assembly display window. This window displays I he dis- 
assembled machine insl ructions for I he program being 
debugged. 

• Traceback display window. This window displays the current 
dynamic call chain of the tar get program. 

• Variable display window. This window displays the values of 
variables or memory ranges for which vvatchpoinls have 
been set. When a watched value changes. HP DDE suspends 
execution, notifies the user of the change in value, and 
updates (he variable display window with I he new value. 

Context-sensitive pop-up menus allow the user lo access 
common debugger commands with the mouse. Menus ap- 
pear when the mouse is clicked. The menu thai appears de- 
pends on the position of the mouse within a particular win- 
dow at Ihe time the mouse is clicked. For example, clicking 
on Ihe mouse with the cursor positioned in Ihe source code 
region brings up Ihe menu displayed in Fig. 2. The cursor in 
Fig. 2 was positioned at Ihe opening bracket of the expres- 
sion list[i] at the lime the mouse was clicked. The menu was 
thus seeded with the expression list[i). If the cursor had been 
positioned over list, the menu would have been seeded wiih 
list instead of list[i|. The mouse can be positioned to prinl 
complex expressions in source programs without requiring 
the user lo type in the expressions. 

For even quicker access, double-clicking causes IIP DDE to 
execute the first menu item instead of displaying Ihe menu. 
The default pop-tip menus contain actions lhal are commonly 
performed by users. However, pop-up menus can be easily 
reconfigured by users lo contain actions lhal are common to 
a particular application. 

Debugging Optimized Code 

At a high level, Optimization can be described as modifying 
instructions and memory references lo improv e program 
performance. Multiple source statements may map to Ihe 
same machine instruction. In some cases source Statements 
may not correspond to any machine instructions. Variables 
may be moved from memory into a register or from one 
register lo another to eliminate cosily memory references. 
Unless a debugger has some way of knowing how- source 
statements and machine instructions have been rearranged 
and where a variable is located, it can be very difficult lo 
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Distributed Debugging Envfaonment - Session 18778 



Program Monitor Information Interface Property Miscellaneous 



Help 



Step -over 
Step 
Go 
Traceback 

Env op 
Env down 
Quit-. 



Executing laage :n process 18796: Vusers/ho_g;bscin/dde/tes' 
Break at: \\average\*ain\32 
dde> step 

Stepped to: \\average\prmt_average\22 
dde> step 

Stepped to: Waver age\sua\ 12 
dde> print low 
\\average\sum\low: 0 
dde> print high 
\\average\sum\high: 9 



dde> 



dde Session 18778 Source Code Display 



' users/ho_gi bson/ dde/t est /aver age . c 



9 
10 
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int sum (list, low, high) 
int list[], low, high; 

int i, s - 0; 

for (i - low; l <- hiah; i+t) 

s list[i]; 
return (s); 



void print_averaae (list, low, high) 
int list[], low, high; 



(b) 



dde Session 18778 Traceback Display 

1 . SST4PTJ (00001934) 

2 _start (80040F24) 

3 T\average\main\32 (00002044) 

1 \\average\print average\22 (00001FB8) 

'^tm i . um\12 



(cl 



\1 dde average 
0 



Idl 



Fig. i. Some "i Che windows 
involved in a typical HI' DUE 
debugging session, (a) 'IViinscript 

display window (i.) Sovice code 
display window (<-') Traeebauk 
display window, (di Targel 

program window 



ilde Session 1U383 Source Code Display 



/d lsk3/users/ho_gibson/dde/t est/average . c 
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int sum (list, low, high) 
int list I], low, high; 
: 

Int 1, s - 0; 

for (1 • low; i <- high; i++) 

s listji]; 
return (s); 



void print_average (list, low, hiqh) 
int list [ ] . low, high; 

int total, num elements, average; 
total - sum (list, low, high); 
num_elements - high - low; /' not< 



print list|il 

watch list(i| 

describe list[l] 

print -hex list|i] 

print (deref once) list|ij 

print (chase ptrs) list| l| 

break listli) 

■ Cancel - 



Fig. 2. \ rollli-M-scnsltlVe pop-Up 

menu. This menu was obtained 

\i\ positioning Hie tnotise enrsor 
(delinli'd l>y 1 1 if larel on line l-l ) 

in the source code display window 
and liicking on a mouse button. 
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inl «, 



Workstation / X Terminal 
{Local Hostl 



x = ft 


Range 1: 


while (x < 101 


x in R3 


hh**y, 




g(&xl; 


Range 2: 


return x; 


x in SP - 60 



Fig. 3. Example Of range locations. Variable x has two locations: 
register 3 in Range 1 and fin hyles below the top-of-star k in Range 2. 

debug an optimized application at the .source level. Program- 
mers often must resort to debugging at the assembly level to 
gain an accurate understanding of program execution. 

HP I»l >E contains some support for debugging optimized code 
at the source level. However, these features are only usable 
if the compiler provides adequate debugging information. 

On EEP Apollo's Domain/OS. the compilers produce range 
locations for variables (see Fig. 3). The range location record 
contains a program counter range and a location for the vari- 
able l hat is correct for the range. A variable may also have a 
default location so that its range locations need not cover 
the entire instruction ranges in which the variable is active. 
Additional information is provided containing the many-to- 
many mapping between source Statements and machine 
instructions. Currently on Hie HP-UX Operating system only 
the mapping between source lines and machine instructions 
is provided. 

Given the appropriate information from a compiler, IIP DDE 
can indicate the source lines associaled with a particular 
machine instruction and the machine Instructions for a par- 
ticular source line. This type of information can help t he 
user determine the flow of control in an optimized program. 
When the user wants to see the value of a variable. HP DDE 
determines the correct symbol location based on the current 
program counter and the range local ion information stored 
for that symbol. 

See "Compiler Optimizations and Debugging" on page 37 
for a short discussion aboul the importance of debugging 
optimized code. 

Remote Debugging 

HP DDE is capable of debugging programs miming on a 
remote system. This can be accomplished by running most 
of HP DDE on a remote system and redirecting input and 
output to a local host, or by running most of HP DDE on the 
local system and the application and a small pail of HP DDE 
on the remote system. The latter approach is currently only 
available on local hosts running Domain/OS. 

To run HP DDE remotely on a typical UNIX"* workstation, 
the user can simply run HP DDE on the remote system and 
redirect the OSF/Motif user interface to the X display on the 
local host (see Fig. 4a). The X Window Systems portability 
allows HP DDEs user interface lo be displayed on any sys- 
tem that supports the X protocol. 

Alternativ ely, ihe user can execute must of HP DDE on a 
local host running Domain/OS while the application pro- 
gram executes on a remote system ( Fig. 4b). A small part of 
HP DDE must also execute on the remote system to handle 
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Fig. 4. Two possible remote HP DDE sessions, (a) Most of HP DDE 
anil the application being debugged are run Oil a remote system and 
the HP DDE user interface is run from an X terminal, (b) Most of HP 
DDE Is run on a local host and a pin t inn of HP DDE and the appli- 
cation are run on a remote system. 

communication between the remote and local systems. This 
is a useful method for debugging programs if the remote 
system cannot run HP DDE on its own, as is often Ihe case 
for embedded systems or prototype systems. 

The implementation of IIP DDEs remote debugging capability- 
is described later in this article. 

Comparisons to Other Debuggers 

Dbx" 1 and gdb" are two commonly used workstation debug- 
gers and Dbxlool, 1 ' which is a window- and mouse-based 
debugger built on top of dbx. is also well known and has a 
graphical user interface similar to that of HP 1)1 >E. None of 
these debuggers has the range of features for supporting 
event-based debugging provided by HP DDE. The dbx and 
dbxtool command languages do not allow the user to de- 
clare new variables during debugging sessions and do not 
contain loops or conditional statements. In addition. HP 
DDE has a larger number of options for specifying monitor 
points at different levels of granularity than dbx and 
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dlixtnol. The gdb command language does not contain loops 
or conditionals. 

Several event-based debuggers have been developed as re- 
search prototypes. Unlike HP DDE. they are not available as 
commercial products. Dalek 1 is a sequential event-based 
debugger w hich is an extension of gdb. Dalek allows high- 
level events to be defined from combinations Of lower-lev el 
events. Dalek is superior to HP DDE in providing the ability 
to define high-level events. However. HP DDE is probably 
easier to use because our goal has been to provide the user 
with powerful event -based debugging features which can be 
used with little effort. A number of event-based debuggers 
have been developed for parallel and distributed systems. 7 fi " 

Several people have looked at the problem of debugging 
optimized code. Hennessy 1 " presents algorithms 1'or deter- 
mining the value of variables in an optimized program. When 
the debugger is stopped at a breakpoint and the user tries to 
print a variable x. the debugger should output the value of x 
that is consistent with the order of execution of statements 
in the unoptimized program. Since the optimizer can reorder 
statements, the value stored in the memory location for x 
may not be the value the user expects to see. Hennessy pro- 
vides an approach for calculating the value of x when the 
value stored in the appropriate memory location is not the 
value the user expects to see. A debugger called DOC - " uses 
an approach that is similar to that of Hennessy and has bet- 
ter capabilities than HP DDK for determining the value of 
variables. Convex 1 - has developed a production-quality tie- 
bugger with elaborate features for debugging optimized code. 
The i onvex debugger uses visual highlight ing of source and 
assembly displays to indicate the flow of control in an opti- 
mized program. HP DDE does not have any of the visual 
highlighting features present in the Convex debugger. The 
SELF debugging system 13 shields the debugger from com- 
piler optimizations by dynamically deoptimizing code. SELF 
uses dynamic compilation which means that instead of com- 
piling entire programs prior to execution, code is generated 
incrementally at run time and kepi in a cache. Dynamic- dc- 
optimization is generally not feasible for languages that do 
not use dynamic compilation. In addition, this approach is 
insufficient for hugs thai occur in the optimized version of a 
program bUl not in the unoptimized version. 

Architecture 

As a class of tools, debuggers perform a wide range of 
operations from very low-level, target-specific operations to 
middle-level, language-specific operations to high-level user 
interface operations. Because of the nature of these opera- 
tions a debugger can be difficult to port and retarget. 

IIP DDF has been designed in a modular fashion with the 
goal of isolating object code dependent, language dependent, 
target dependent, and user interface dependent functions 
from generic debugging functions. The IIP DDF architecture 
consists of a main debugger and several managers, which 
are categorized according to language, target, object code, 
and user interface type (see Fig. - r >). 

The main debugger is designed to provide as many generic 
debugger operations as it can without compromising the 
generality, of IIP DDF. Examples of these operations include 



Compiler Optimizations and Debugging 

The object code produced by 5 compiler using straightforward compiling techniques 
;S often not very efficient in many cases, the object code can be made tc- run faster 



optimizing compilers 

•n an uwptKrwed program, there is generally a one- to-one correscondenre between 
a source staicmen, arsj a gnxip or one or mor- macnine instruction* optimizing 
compilers must preserve the correctness of a program, but after optimization, this 
one-to-one correspondence no longer exist! in many cases, and the program may 
no longer execute m the order implied by the source code This complicates de- 
bugging Programmers must often resort to debugging assembly code to figure out 
how an optimized program is behaving 

In general, users should debug the unoptimized version of a program before using 
the optimizer However, there are a number reasons why the ability to debug 
optimized code is desirable 

• A program may run correctly when compiled without optimization and fail when 
compiled with optimization This can happen even it the optimizer is working 
correctly For example, reordering statements may result in arithmetic overflow or 
underflow An uninitialized variable or an out-of-bounds memory reference might 
cause a problem in the optimized version but not in the unoptimized version. 

• The time or space requirements ol an unoptimized program might be too big to 
allow adequate testing 

• Production code is often optimized A customer may submit a bug report with a 
core file produced from an optimized program It would be desirable to have the 
ability to analyze the core file. 

• Optimizing compilers can be written more easily with good tools lor debugging 
optimized code 

• The compiler may not have the ability to generate unoptimized code 

• The programmer may have mistakenly supplied explicit assertions, directives, or 
options that caused the optimizing compiler to generate incorrect code 

• Optimizing compilers may have Dugs 



symbol Cable and program monitor management, The manag- 
ers perforin operations thai are specific to a given machine, 
language, compiler, or user interlace. Each manager has an 
interface specification that defines the operations a particular 
manager should provide. A manager is formally defined as 
any piece of software thai correctly implements I he functions 
defined in the interface specification. 

The main debugger also has a set of functions called callback 
Junctions that managers can invoke to obtain information 
from the main debugger. As the main debugger satisfies a 
user command, it can call on the various managers to per- 
form operations provided by a particular manager And while 
a manager is satisfying a request from the main debugger it 
can request information from the main debugger through a 
callback function. 

Managers do not communicate with one another because HP 
DDE is Structured so thai it should not be necessary. This 
strict partitioning allows a developer to port and retarget a 
manager or develop a new manager as necessary without 
modifying other managers or the main debugger. 

In the main debugger and managers, platform-specific system 
calls are avoided except in the lowest-level parts of the man- 
agers. However, system-specific calls arc generally needed, 
so we have implemented a set of general-purpose utilities, 
pari of which can be customized for the target platform 
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Fig. 5. HP DDE consists of a main 
debugger and several managers. 
Three user interface managers, 
eight language managers, four 
object code managers, and five 
/ large! managers currently exist 
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They are generally independent of the functions of a debug- 
ger and can be used by any application. In all of the system- 
specific calls we try to be compliant vviih the latest version 
of POS1X. 

These general-purpose utilities include a list utility, a hash 
table utility, a memory allocation utility, and a string handling 
tililiiy. The memory allocation utility provides a generic inter- 
face to system memory management functions such as malloc 
and free. It allows a caller to allocate memory directly from 
the heap or to allocate a cluster of storage, which is man- 
aged separately from the rest of the heap and from which 
smaller pieces of memory can be allocated later. 

Because of the partitioned implementation scheme, HP DDE 
can support a wide variety of target machines, languages, 
object code formats, and user interfaces simply by imple- 
menting new managers. Although implementing a new man- 
ager is not a trivial task, supporting a new architecture or 
object code formal is generally straight forward. 

The Main Debugger 

The main debugger constitutes the largest and most complex 
pail of HP DDK. It contains the implementation of generic 
debugger operations that control and maintain information 
about a debugging session. The design of HP DDE Ls such 
that most debugger functionality resides in the main debug- 
ger so that managers can be small and easy to implement. 
The main debugger supports a wide variety of platforms and 
block-structured languages but makes few assumptions about 
their specific properties. When the main debugger needs 
target, language, or object code dependent information it 
calls a manager to supply it. 



Just as HP DDE is divided into the main debugger and vari- 
ous managers, die main debugger is further subdivided into 
several distinct packages, each of which implements a well- 
defined subset of the operations provided by the main de- 
bugger. Although the main debugger is not written in C++, it 
has been implemented using an object -oriented methodology, 
and a package is similar to a class. Each package defines a 
function interface to the data it controls, such that one pack- 
age can only refer to die data in another through the function 
interface. Parts of these package interfaces are exported as 
callback functions for use by the various managers. 

Most of the services provided by the main debugger fall into 
one of the following categories: symbol table management, 
command dispatch and processing, program monitor man- 
agement, abstract syntax tree construction and expression 
evaluation, stack management, location identifier parsing, 
target program execution management, user interface dis- 
play management, and short-term and long-term storage 
management. 

Symbol Table. HP DDE s symbol table is managed by the 
main debugger and initialized by the object code manager 
through callback functions. The symbol table isolates the 
main debugger from differences in debugging information 
emitted by different compilers and is versatile enough to 
represent programs in all languages that HP DDE supports. 

Other parts of the main debugger and other managers can 
call the symbol table package to obtain information from the 
symbol table. Although IIP DDE is dependent on the cor- 
rectness of the symbol lable. as is any debugger. IIP DDE 
does not assume that the symbol table is complete. If a 
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piece of information is noi in the symbol table, an error 
does not occur. This behavior requires the caller to check to 
see if the symbol table package returns the expected piece 
of information. 

See "A Short Primer on Debugger Internals" at right for 
more about symbol table use during a debugging session. 

Abstract Syntax Trees and Expression Evaluation. To remain as 
language independent as |Kissible. the main debugger imple- 
ments an abstract syntax tree construction package. Lan- 
guage managers call this pac kage to generate intermediate 
languaget trees representing language expressions. The 
intermediate language is powerful enough to represent 
most expression constructs for all languages that IIP DDE 
supports. 

Once a language manager has constructed a language inde- 
I indent intermediate language tree for a language expression 
specified by the user, the tree is returned to the main debug- 
ger for processing by the expression evaluator package. The 
evaluator calls oilier packages and managers to determine 
the \alue and type of the expression. 

During expression evaluation, some language-specific infor- 
mation may be needed. For example, arrays are laid out in 
column-major formal in some languages and in row-major 
format in others. Other language dependent abstractions 
include the case-sensitivity of the language, whether a string 
is null terminated, various attributes of arrays and pointers, 
and type-checking rules. Like the set of intermediate lan- 
guage constructs HP DDE supports, this group of language 
abstractions is meant to be representative. For example, the 
main debugger knows the variety of ways arrays are treated 
in different block-structured languages and how to treat 
each one correctly. However, the main debugger does not 
know the language of the expression, but only the value of 
the particular attribute. 

Short-Term and Long-Term Memory Management. Because HP 
DDE is implemented in a strictly partitioned manner, man- 
agement of heap storage can be difficult. One package or 
manager can allocate a piece of data, but has no way of 
knowing when it can be freed. To simplify this problem, the 
main debugger uses the general-purpose memory allocation 
utility mentioned earlier to Implement a higher-level storage 

package. 

A) the start of execution the main debugger allocates a 
cluster of storage, which it uses as temporary space. Callers 
to the higher-level storage package can request a piece of 
the temporary cluster for storage that is needed only briefly 
rather than throughout a debugging session. A package or 
manager that requests this temporary space does not need 
to be responsible for freeing it because the entire cluster is 
freed and reallocated at the end of each command execution 
cycle. 

For example, the abstract syntax tree package allocates 
intermediate language nodes in temporary storage because 
the types and values of expressions are determined within 
one command cycle, and the information is no longer needed 
once it has been displayed to the user. < >n the other hand. 



t An inlefmed'Bte language is o language that 15 used as an intermediate step between the 
original (high levell suuict code and the (low-levell target language 



A Short Primer on Debugger Internals 

When using a debugger, the user typically wants to be able to stop the program at 
various times during execution, print trie value of a program symbol, follow the 
program flow of control by stepping through the source lines in a function, or 
examine the program execution stack to determine how execution ended up at a 
particular location 

access to a lot of information much of it related to program bioexs. symbols, data 
types, and source Imes Many debuggers read this information from the object 
code file and store n m an internal symbol table for easy lookup and traversal 

A debugger uses the information m the symbol tabl6 to translate a symbolic loca- 
tion specified by the user into a virtual address Once a debugger has a virtual 
address for a program location, it can set a program monitor (such as a breakpoint 
trace, or watchpomt) at that location Once the virtual address for a program 
symbol is known, a debugger can find its value and display the value according to 
the symbol's type 

To determine the type and value of a language expression specified by the user, 
which may range from a simple variable reference to a complex expression, a 
debugger needs same way to determine if the expression is correct One way to 
implement this functionality is with a parser that translates the expression into 
some son of abstract syntax or intermediate language tree made up of operator 
nodes and operand leaves This tree is then evaluated to determine the type and 
result value of the expression 

The contents of the symbol table are important to a debugger, but it also needs 
access to the address space of the target program On many UNIX systems, de- 
buggers control the target program with the ptracel) system call With ptracel) a 
debugger can read from and write to the program's address space, execute the 
program tor one or many instructions, and send a signal to the program For exam- 
ple, once a debugger has translated a program location into a virtual address, it 
uses ptracel) to write a special instruction into the instruction stream of the target 
piogram Execution of the special instruction causes the target program to stop 
and the debugger to regain control of the target program 



symbol table and breakpoint information is allocated in long- 
term storage because it is needed throughout a debugging 

session. 

Target Managers 

Target managers are responsible for providing debugger 
functionality specific to the hardware, operating system, 
and run-time libraries. Since these components lend to be 
platform-specific, it is critical to isolate the dependencies on 
these components from the main debugger. 

The two major goals in isolating platform-specific dependen- 
cies within target managers are lo make it easier to purl HI* 
DDE to a new platform and to facilitate remote debugging 
on heterogeneous systems. 

The target manager's primary responsibility is to control the 

program being debugged and report the state Of the program 
to the main debugger. A carefully defined interface has been 
created to hide the details of how a program is controlled and 
inspected. These details often vary widely between hardware 
platforms, operating systems, and run-lime libraries. 

Ill' DDE supports debugging of threads based on the !'< (SIX 
threads model. Each thread has a unique register set, stack, 
and call chain. Every (bread in a program can be examined 
by the main debugger. The target manager hides the details 
11I a threads implementation. For example, currently Ofl the 
lll'-l X operating system, thread control is implemented 
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using a run-lime library. However, on Ihc Solaris operating 
system, thread control is embedded in ihe kernel. 

The target manager uses an event-driven model to communi- 
cate with the main debugger. The main debugger directs the 
target manager to resume the program and report back 
events when execution is hailed. Program events are trig- 
gered by several circumstances, including breakpoints; data 
watchpoints. traces. faults such as UNIX signals, shared 
library loads and unloads, program forks and execs, ihread 
creation, termination, and context switching, and C++ 
exception catches and throws. 

For every event, the current program counter and stack 
pointer are reported to the main debugger. The target man- 
ager also constructs the dynamic call chain. Every event is 
associated with a specific Ihread. The thread that triggered 
the event is selected as the primary Ihread, but the main 
debugger can also examine the program counter, stack 
pointer, and dynamic call chain of all other threads in the 
program. For events such as shared library loads, the name 
and address spaces of the shared library are returned. For 
events caused by a faidt such as a UNIX signal the type of 
fault (e.g.. signal number) is relumed. 

When Ihe target program is halted, the target manager pro- 
vides a Variety of services to the main debugger. The currenl 
state of ihe program can be queried or modified. Machine 
registers and memory can be altered, and program functions 
can be called. Thread scheduling order and state can be 
changed. Program forks and execs can be followed lo debug 
the new process. For program forks, both t he parenl and the 
child can be debugged simultaneously. A separate debugger 
is spawned lo debug Ihe child program. 

The target manager also handles issues related lo run-lime 
libraries. Run-lime libraries tend to vary with hardware plat- 
forms and operating systems. An example of this is the C++ 
run-time library. The implementations of certain language 
features, such as exceplion handling, are embedded in the 
C++ run-time library. HP DDE's target manager interfaces 
with this library and handles events such as throws and catches. 
For example, lo stop on a C++ throw, the target manager sels 
a hidden breakpoint on the run-time routine that handles 
throws. After the hidden breakpoint is triggered, the call 
chain can be followed to find Ihe user routine thai issued 
Ihe throw. 

Remote Debugging Capabilities 

As mentioned earlier. HP DDF supports remote debugging in 
two different ways. The fust way is lo run most of IIP DDE 
on a remote host and redirect input and output to a local 
host, and the second way is to run most of HP DDE on the 
local host and the rest of IIP DDE and the application being 
debugged on ihe remote system. This section describes the 
second way. 

HP DDEs remole debugging capabilities are handled by the 
target manager. HP DDE is Started on a local host system 
and instructed by the user to debug an application executing 
on a remote target system. A portion of Ihe target manager, 
the target debug kernel, also executes on ihe remote system 
(see Fig. 0). The main part of the target manager runs on Ihe 
host and communicates with the target debug kernel. The 
target debug kernel interfaces with the hardware, operating 
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Fig. 6. Remote debugging session showing the distribution of the 

target manager software, 

system, and run-time libraries of the remole system. Com- 
munication between the host and remote system is handled 
entirely by the interface between the target debug kernel 
and the rest of the target manager. Other DDE managers and 
Ihe main debugger are not aware of the interface between 
(he host and remote system, or even the fact that the target 
program is executing on a remote system. 

The method for communicating between the local host and 
remote system depends on the protocols common to both 
systems. One possibility is to communicate via remote pro- 
cedure calls. This is Ihe protocol used for remote systems 
running the HP Apollo Domain/OS. Embedded systems thai 
do not support remote procedure calls might use a simpler 
protocol. 

Remote debugging is most useful when the target system 
does not have all the functionality or resources to run IIP 
DDE. For example, when porting HP DDE to HP Apollo's 
PRISM system, remote debugging was needed during early 
development before the operating system and run-time sys- 
tem were fully functional. Remote debugging can also be 
used to lessen the load on ihe remote syslem. Since all but a 
small piece of HP DDE is running on (he local hosl system, 
the local host supplies resources such as memory and CPU 
to ran IIP DDE. 

Object Code Managers 

Object code managers are responsible for converting 
symbolic debug information generated by compilers into HP 
DDE's interna] symbol table format. The object code manager 
functionality was separated from the target manager to take 
advantage of common symbol table formats across target 
platforms. An object code manager that recognizes a partic- 
ular symbol table format can be reused on any platform that 
uses the same symbol table format. 

The object code manager creates HP DDE's internal symbol 
table in several stages. When a program is first loaded, the 
object code manager creates the primitiv e data types that 
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miglu be required by a program (e.g., integral and floating- 
point types in various sizes). The object code manager also 
supplies a mapping from those primitive types to language- 
specific type names (such as char or int for C). 

After the primitive data types are created, the object code 
manager enters information about the program being de- 
bugged into the symbol table. Program information is stored 
hierarchically as a tree. The object code manager creates a 
subtree in the symbol table for each executable file in a pro- 
gram. Each level of a tree is known as a block. Tree blocks 
represent the lexical structure of programs. Blocks contain 
symbol and lute number information for the lexical scopes 
they represent. The root block of each subtree, which con- 
tains symbols global to the executable file it represents, is 
known as an image block. Fig. 7 shows an example of a 
symbol table block. 

Symbol table elements are c reated for each global type or 
variable at program load time. However, symbols local to 
the child blocks of an image block do not have to be created 
immediately. HP DDE can incrementally initialize local sym- 
bols when they are needed. If a block is never referenced, 
the local symbols of the block may never have to be entered 
into the symbol table. HP DDEs startup time and space re- 
quirements are reduced by minimizing the amount of initial 
information in the symbol table. 

After the program is loaded, the object code manager may 
subsequently be invoked if the program dynamically loads a 
new executable shared library. 

HP DDE makes wry few assumptions about the level of 
Support provided by an object code manager. Symbol table 
information can be sparse. An object code manager can pro- 
side limited support for debugging programs that were not 
compiled in debug mode by doing such things as using the 
linker symbol table information. In this case, the level of 
symbolic debug support is reduced. 

Language Managers 

Language managers are responsible for the language-specific 
aspects of a debugging session. A separate language manager 
exists for each language supported by HP DDE. including C. 
C++, Fortran, Pascal, and various assembly languages. Mul- 
tiple language managers can be loaded simultaneously. 

I IP I H IE uses language managers when evaluating and print- 
ing expressions. IIP DDE has a language mode thai deter- 
mines how expressions are evaluated. The default language 
mode is the language corresponding to the current point of 
progr am execution. However, the programmer can override 
the default language mode. Each language manager is re- 
sponsible for parsing expressions according to the syntax 
or the language. If the expression is legal, an intermediate 
language tree representing the expression is created. The 
main debugger evaluates the intermediate language tree in a 
bottonvup fashion and invokes the language manager during 
this evaluation. Tin- language manager is called to type check- 
each nonleaf node in the intermediate language tree before 
the node is evaluated. If a type-checking error occurs. I lie 
language manager can either hall the evaluation process or 
insert type conversion nodes into the intermediate language 
tree to make the operation legal. 



ml sum I Irst. low. highl 
int list." low. high 

i 

int i. s = 0: 

lor li = low, i <= high. i*»l 
return 1st 

1 

= block V imagela outteverage^sum = 

name: sum 
starljine.nr 12 
end line nt 19 

sourcejile average c iMon Jul 2511 1053 1994> 
stml list 

— statement w'imagel a out r\average^um\1 5 
line_nr. 15 
start ottser. 16 
end offset 19 

statemenl W'imagela outt\average\sum\12 

line nn12 
stan offset 0 
end offset 15 

— statement W'imagela out )\average\sum\16 

line_nr: 16 

stan offset: 20 
end offset 39 

— statemenl W'image(a.outF\average\sum\17 — 
line_nn 17 

starl offset 40 
enOffset 91 

— statement W'imagela oul[>average\sum\18 — 
line_nr: 18 

start^offset 92 
end offset 99 

— statement W'imagela outl\auerage^um\19 

line_nr:19 

start_offset 100 
end.offset: 107 

sym list: 

— symbol W'imagela oull\average\sum\Jist — 
name: list 

datatype: pointer 
attributes: ! param by val 1 

— symbol W'imagela. out |\average\sum\Jow — 
name: low 

datatype: int 

attributes: I param by val 1 

— symbol W'imagela. out)\average'*sunWiigh — 
name: high 

datatype: int 

attributes. | param by val 1 

— symbol W'imagela.out|\average\sum\j — 
name: i 

datatype: int 

attributes: [ slack variable ] 

— symbol W'imagela oull\average\sum\s — 
name: s 

datatype: int 

attributes: I stack variable | 

Fig. 7. Si mic of iln- information cruiuiined in a symbol table block 
for the function sum. which is pari of a larger G prugruiii. 

A language manager performs a number of auxiliary func- 
tions as well, including formatting data for output and defin- 
ing the value of several attributes that the main debugger 
uses lo conform to the behavior of the language currently in 
effect. Examples include whether identifiers are case sensi- 
tive, whether an array of characters is equivalent to a string, 
or Whether a pointer can be indexed as if it were an array. A 
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language manager also determines how text is selected from 
I IF DDE's user interface displays. The user interface can 
define a point-and-click operation to select arguments for 
debugger commands. When a user clicks a mouse button on 
text displayed somewhere in I he user interface, the current 
language manager determines the text the user is referring 
to from the position of the mouse cursor (see Fig. 2). 

User Interface Managers 

The main role of a user interface manager is to collect user 
input, convert user input into debugger commands, send 
commands to the main debugger, and display output from 
the main debugger. As described earlier, five different out- 
put areas are defined in HP DDE: the source code display, 
assembly code display, stack traceback display, watched 
variable display, and transcript display (see Fig. 1 ). The user 
interface specification allows considerable freedom in the 
way these displays are implemented. A user interface can 
ignore output for every display except the transcript display, 
which records the interactions between the user and HP 
I >DK. ( 'ommands exist to enable and disable the other dis- 
plays and to redirect output intended for Other displays to 
the transcript display. 

A user interface is dynamically loaded by the main debugger 
at startup time. Although several user interfaces exist, there 
is no way to switch user interfaces after one has been spe- 
cified at startup time. 

The most sophisticated user interface provided by HP DDE 
is the GUI described earlier. A more primitive line mode 
user interface also exists for systems that do not support X 
Windows and OSF/Motif. 

Implementation Experiences 

Our experiences with the IIP DDE architecture have been 
positive, and its design concept has been validated by the 
number of times HP DDE has been ported* The interface 
specifications allow developers to write new managers with- 
out worrying about other pans of IIP DDE. However, we do 
pay a price for such an extreme level of generality and ab- 
straction. For instance, our source line count is currently 
hovering around 250,0(111 lines, which is high compared with 
the dhx and gdb debuggers. Machine resources consumed 
by HP DDE can be quite substantial, particularly when de- 
bugging large programs. In addition, performance can be 
suboptimal because several function calls must be made 
nearly every time a piece of information is needed from 
another part of the debugger. 

Although the original designers of the HP DDE architecture 
did an exceptional job designing and implementing the de- 
bugger abstractions, some assumptions did creep in. For 
instance, it is fairly straightforward to support a procedural, 
block-structured language, However, we recently imple- 
mented extensive C++ support and certain aspects of the 
implementation were rather difficult because of various 
features of the language such as inheritance and dynamic 
type identification and the dependence on the run-time sys- 
tem. To preserve modularity, the interface specifications do 
not allow one manager to make a direct call to a function in 
another manager. However, the implementation would have 



been easier if the language manager had the ability to make 
direct calls to target and object code manager functions. 

One of the problems in developing HP DDF has been the 
partitioning of debugger functionality into a main debugger 
and different managers. The goal has been to put as much 
functionality as possible into the main debugger while keep- 
ing IIP DDK as general as possible. While most of the origi- 
nal manager interface specifications are still valid, modifica- 
tions have been necessary, For example, the target manager 
interface specification was modified extensively to provide 
multithreaded debugging support. Also, the language man- 
ager interface specification was modified "» enable more 
extensive C++ debugging support. 

In addition. IIP DDE was originally implemented on IIP 
Apollo's Domain/OS, which provided a great deal of support 
for different aspects of debugging, including a procedural 
interface to the shared library loader and an enhanced ptracel) 
(process trace) facility that allowed the debugger to follow 
the child of a forked process. Parts of the manager and call- 
back interfaces were designed with this additional operating 
system support in mind. Consequently, target -related Opera- 
tions and event processing are often more complicated on 
1 NIX implementations with less sophisticated debugging 
support. 

One deficiency that HP DDK has in common with many other 
debuggers is the performance of watchpoints and conditional 
breakpoints. In HP DDK, watchpoints are implemented by 
setting hidden breakpoints at the granularity requested by 
die user and monitoring data at these breakpoints. Kach 
time execution stops at a hidden breakpoint, the current 
value of the data must be compared against the old value. If 
the monitoring interval is short, a great deal of time is spent 
slopping at breakpoints and performing comparisons. 

Conditional breakpoints are implemented in a similar fash- 
ion. The expression specified by the user is stored with the 
breakpoint information. Kach lime execution reaches the 
conditional breakpoint, the expression is parsed and evalu- 
ated. Depending on the complexity of the expression and 
the frequency with which the breakpoint is triggered, this 
can be time-consuming. 

Conclusion 

IIP DDK is a multilingual debugger that has been ported to 
several different platforms. Event-based debugging features 
allow the user to debug programs at a higher level than 
would otherwise be possible. HP DDK also has the ability to 
debug applications running on remote systems and to debug 
optimized code. The sophisticated GDI provides many fea- 
tures that aid usability, including multiple windows, context- 
sensitive pop-up menus, and online help. 

IIP DDK's modular architecture consists of a main debugger 
and several managers. The managers encapsulate dependen- 
cies on target platforms, object code formats, languages, and 
user interfaces. Manager interface specifications indicate 
the services required from new managers to support new 
target platforms, object code formats, languages, and user 
interfaces. 
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Wavelet Analysis: 
Theory and Applications 

Wavelet analysis has attracted attention for its ability to analyze rapidly 
changing transient signals. Any application using the Fourier transform 
can be formulated using wavelets to provide more accurately localized 
temporal and frequency information. This paper gives an overview of 
wavelet analysis and describes a software toolbox created by HP 
Laboratories Japan to aid in the development of wavelet applications. 

by Daniel T.L. Lee and Akio Yamamoto 



Wavelet analysis (also called wavelet Iheoiy, or .just wave- 
lets) has attracted much attention recently in signal process- 
ing. It has heen successfully applied in many applications 
such as transient signal analysis, image analysis, commu- 
nications systems, and other signal processing applications. 
It is not a new theory in Hie sense that many of the ideas and 
techniques involved in wavelets (subband coding, quadra- 
ture mirror Biters, etc.) were developed independently in 
various signal processing applications and have been known 
for some time. What is new is the development of recent 
results on the maihemaiical foundations of wavelets that 
provide a unified framework for the subject. 

Within this framework a common link is established be- 
tween the many diversified problems that are of interest to 
different fields, including electrical engineering (signal pro- 
cessing, data compression), mathematical analysis (harmonic 
analysis, operator theory), and physics (fractals, quantum 
field theory). Wavelet theory has become an active area of 
research in these fields. There are opportunities for further 
development of both I he mathematical understanding of 
wavelets and a wide range of applications in science and 
engineering. 

Like Fourier analysis, wavelet analysis deals with expansion 
of functions in terms of a set of basis functions. Unlike 
Fourier analysis, wavelet analysis expands functions not in 
terms of trigonometric polynomials but in terms of icarrlcts, 
which are generated in the form of translations and dilations 
of a fixed Function called the mother mirHi'l. The wavelets 
obtained in this way have special scaling properties. They 
are localized in time and frequency, permitting a closer con- 
ned ion between the fund ion being represented and I heir 
coefficients. Greater numerical stability in reconstruction 
and manipulation is ensured. 

The objective of wavelet analysis is lo define these powerful 
wavelet basis functions and find efficient methods for their 
computation. Il can be shown that every application using the 
fast Fourier transform (FFT) can be formulated using wave- 
lets to provide more localized temporal (or spatial) and fre- 
quency information. Thus, instead of a frequency spectrum. 



for example, one gets a wavelet spectrum. In signal process- 
ing, wavelets are very useful for processing nonstationaiy 
signals. 

Wavelets have created much excitement in the mat hematics 
community (perhaps more so than in engineering) because 
the mathematical development has followed a very interest- 
ing path. The recent developments can be viewed as resolv- 
ing some of the difficulties inherent in Fourier analysis. For 
example, a typical question is how to relate Ihe Fourier co- 
efficients to the global Or local behavior of a function. The 
developmenl of wavelet analysis can be considered an out- 
growth of the Littlewood-Paley theory 1 (first published in 
1931), which sought a new approach to answer some of 
these difficulties. Again, it is the unifying framework made 
possible by recent results in wavelet Iheoiy related lo prob- 
lems of harmonic analysis ( also to similar problems in oper- 
ator theory called the Calderon-Zygmund theory 1 ) that has 
general ed much of the excitement. 

In electrical engineering, there have been independent devel- 
opments in the analysis of nonstal ionaiy signals, specifically 
in the form of the short-term Fourier transform, a variation 
of which called the Gabor transform was rust published in 
1946.-' A major advance in wavelet theory was the discovery 
of smooth mother wavelets whose set of discrete translations 
and dilations forms an orthonormal basis for I,-(R), where R 
is the real numbers and L 2 is the set of all functions, f. thai 
have bounded energy, dial is, functions for which 




|f(Y)| 2 dt < * . 



This is a main difference from the Gabor transform. In the 
Gabor case, no orthonormal basis can be generated from 
smooth wavelets. Thus the unifying framework brought 
about a better understanding and a new approach that over- 
comes the difficulties in the short-term Fourier iransform 
methods. 

In ihe next section we give an overview of the main features 
of wavelet analysis and then torn to a software toolbox that 
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IIP Laboratories Japan has developed to help in die develop- 
ment of wavelet applications. 

For an excellent tutorial introduction to the subject, see 
Rioul and Vetterli- and the references therein (it lists 106 
references). Daubechies' book' is a standard reference on 

the subject- 
Fundamentals of Wavelet Theory 

This section gives a quick overview of ihe main formulas. 
The Analyzing Wav elet 

Consider a complex-valued function ij> satisfying the follow- 
ing conditions: 



[ 



!t|i(t)fdt < * 



da < *. 



(2) 



whore 4 1 is the Fourier transform of y. The first condilion 
implies finite energy of the function ip. and the second condi- 
lion. (he admissibility condition, implies that if 'I'do) is 
smooth then »C (0) = ft 

The function ip is the mother wavelet. 
Continuous Wavelet Transform 

If i|' satisfies the conditions described above, then Ihe wave- 
let transform Of a real signal s(l ) with respect to ihe wavelet 
function i|»(t) is defined as: 



S(b,a) = -4 f 



t - b 



)s(t)dt. 



(31 



where tjr' denotes the Complex Conjugate of i|\ and this is 
defined on Ihe open (b.a) half-plane (I) e R, a > 0). The 
parameter 1) corresponds to the lime shift and the parameter 
;i rorrcsponds to Ihe scale of ihe analyzing wavelet 



If we define i|'.,.i,(l ) as 

-!',,.,(» = a" ''-,|.(^ 



which meiULs reselling by a and shifting by b, then equation 3 
can be written as a scalar at inner product of the real signal 
s(t) with Ihe function i|' n ,i>(') : 



S(b.a) = 



When function i|'(l I satisfies the admissibility condition, 
equation 2. Ihe original signal s(l ) can be obtained from the 
wavelet transform S(b,a | by the following inverse formula: 



s(t) = A 



Stb.aj.r.,,!!! 



dadb 



(6) 



Discrete Wavelet Transform 

In Ihe discrete domain, the scale and shift parameters are 
iliscreii/.ed as a = a[" and b = nl>n, and ihe analyzing wave- 
Ids are also iliscretized as follows: 



(7) 



where m and n are integer values- The discrete wavelet 
transform and its inverse transform are defined as follows: 



V'nui(Os(t)dt. 



s(t) = k v V V SmnVmn (t), 



(S) 



where k v is a constani value for normalization. 

The function i|'„ u ,(i) provides sampling points on Ihe scale- 
time plane: linear sampling in the lime (b-axis) direction but 
logarithmic in the scale ( a-axis) direction. 



(V) The most common situation is that an is chosen as: 



ao = 



(10) 



where W is an integer value, and that v pieces of i|',i U1 (t) are 
processed as one gr< nip. which is called a rnii i The integer v 
is die number of voices per octave; il defines a well-tempered 
scale in the sense of music. This is analogous lo ihe use of a 
sel of narrowband filters in conv entional Fourier analysis. 

Wav elet analysis is not limited to dyadic scale analysis. By 
using an appropriate number of voices per octave, wavelet 
analysis can effectively perform the 1/3-oetave, 1/6-octave, 
or 1/12-octave analyses I hat are used in acoustics. 

The main foc us of current research is on finding optimal 
wavelet basis functions and efficient algorithms for comput- 
ing the corresponding wavelet transforms. The wavelet basis 
function can be implemented as an FIR (finite impulse re- 
sponse i filler or an IIR ( infinite impulse response) filter 
depending cm Ihe particular properties needed. 

Graphical Representation 

This section describes how lo display complex-valued 
functions such as equations 3 and S so that useful informa- 
tion about the signal s(l ) can be highlighted. Then' are two 
aspects lo consider. 

The open (b.a) hall-plane on which the wavelet transform is 
defined can be mapped onto Ihe full plane (b.-log(a)). This 
representation is indispensable if we want lo display, in a 
single picture, information wit h a wide range of scale parame- 
ters. For example, for Bound signals in the audible range, a 
spread often octaves is common. A disadvantage of Ibis 
representation, on the other hand, is that straight lines on 
the open (b.a) half-plane become exponential curves in the 
logarithmic representation. 

Expressions 3 and 8 depend on the choice of the analyzing 
wavelet 4'. To obtain full quantitative information about the 
signal s(i ) from its transform S(b.a), we need to know the 
analyzing wavelet There are. however, many features of 
the signal thai are independent of the choice of i|t Such fea- 
tures involve the phase of Ihe complex-valued functions. 
Therefore, it is useful to represent separately the modulus 
and the phase of Ihe complex-valued function S( b.a) to be 
described. 

Shown in Figs. 1 and 2 is an example of Ihe wavelet trans- 
form of a localized pulse thai approximates a delta function. 
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Fig. I. Magnitude of i he wavelet transform of a delta [unction. 

The horizontal axis is time in both the magniluile picture, 
Fig. 1, and the phase picture. Fig. 2, and the vertical axis is 
scale, with small scale at the top. 

In Fig. 1, the magnitude increases toward the top of the pic- 
ture. The modulus or magnitude. IS(b,a)l. is converted to 
grayscale and is normalized to its maximum, (hat is, the plot 
shows x, where: 



ISI 



IS,, 



< 1. 



(H ) 



The phase of S(b.a) is given by a grayscale picture in which 
a phase of 0 corresponds to white and a phase of 2n (o 
black. This convention is quite useful in interpreting the 
resulting picture, When the phase reac hes 2.T, il is wrapped 
around to the value 0. The lines where the density drops 
abruptly to zero are clearly visible on the picture and play an 
important role in the interpretation as a visible line of con- 
stant phase. In Fig. 2, one can see the lines of constant 
phase pointing to the location of the delta funct ion. 

Examples of Wavelet Funct ions 

Haar Wavelet. The Haar wavelet is the simplest kind of wave- 
let function. Suppose that <p(\ ) is a box function satisfying 
the following: 




Time Shift b 

Fig. 2. Phase of the wavelet transform of a delta function. 



1 if 0 < t < 1 
= jO otherwise. 

If we define the function i|i(t) as i|i(t) = <|>(2t) - <|)(2t-l), we 
can obtain the following function: 



<|'(t) = 



1 if 0 < t < 1/2 
-I if 1/2 < t < 1 
il otherwise. 



The function (p(t) is the Haar scaling function, and ij'O ) is 
the Haar wavelet. This function is orthogonal to its own 
translations and dilations, that is. the family 



<l>m,n(t) = 2- rn/2 >p(2-'»t - n), m,n 6 Z. 



(1-1) 



where Z is the real integers, constitutes an orthonormal 
basis for L-(R). Historically the Haar function was the origi- 
nal wavelet. This wavelet is not continuous, and its Fourier 
transform *P(ii>) decays only like IfflH, Corresponding to bad 
frequency localization. 

Meyer Wavelet. Yves Meyer constructed a smooth orthonor- 
mal wavelet basis as follows. First of all, define the Fourier 
transform <!>(<„) of a scaling function (|>(t) as: 



<!>((,)) = <. 



1 

cos 
0 



N> - 1 



if Itul < =.t 

if 1* < Iwl < |ji (15) 
otherwise, 



where v is a smooth function satisfying the following 
conditions: 



v(t) = 



t) if I < 0 
1 if t > 1 



with the additional property 

v(t) + v(l-t) = 1. 
This function <1> is plotted in Fig. 3. 



(16) 



(17) 



hi this case, the wavelet function i|, can be found easily from 
3>. First, we find the Fourier transform of y. 

u)((,)) = e""/ 2 V <I>(m + 2;t(21 + 1 ))(I>((o/2) (18) 
lez 

= e*»%6(M + 2*) + 4>((u - 2ji)1<I>!.,)/2). (19) 
The function K V is plotted in Fig. 4. 

Now since "J is compactly supported ( its duration is finite 
and nonzero) and y V e Cj, where k Ls arbitrary and may be 
» (i.e., *V has at least k derivatives). ||J can be obtained by 
taking the inverse Fourier transform. Fig. o shows a graph of 
the Meyer wavelet G C J . 

Morlet Wavelet. This particular function was most often used 
by R. Kronland-Martinet and J. Morlet. Its Fourier transform 
is a shifted Gaussian, adjusted slightly so that *V(G) = 0: 



«M = e" l " , - |U o)"'' 2 - e _<u2/2 e _ '"o /2 



V(t) = (e- 



"o' _ e -">- 



-t*/2 



(20) 
(21) 
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Fig. 3. Ki Mirier transform of the scaling function forth'' Meyer basis 

Often COq is ciiosen so that the ratio of the highest maximum 
of n> to the second highest maximum is approximately 1/2. 
that is, 

too = (2/In i) M = 5.13364. . . (22) 

In practice one often takes o>q = 5. For this value of (Do, the 
second terni in equation 20 is so small that il can he ne- 
glected in practice. Consequently, the Morlet wavelet can 
be considered as a modulated Gaussian waveform. Its real 
and imaginary parts for coo = r> arp shown in Figs. 6 and 7, 
respectively. 

The Morlet wavelet is complex, even though most applica- 
tions in which il is used involve only real signals. The wave- 
let transform of a real signal with this complex wavelet is 
plotted in modulus-phase form, that is, one plots l(s, i|'„i,„}l 

1.2 T 




-02 1 1 1 1 

-10 -5 0 5 10 

■ 

Fig. 4. Fourier trtnSftJfm of the Meyer wavelet, 




-1.0 1 1 1 1 

-6 -3 0 3 6 

t 



Fig. 5. The Meyer wavelet 

and tan _1 (Im(s. \f m „)/Re(s. tj'm.h)!- where the brackets indi- 
cate the scalar or inner product of die signal waveform s 
with the basis function t|Wflj that is. 

(s.\l' m .„) = J s(t)i|<'„,.„(t)dt. 

The phase ploi is particularly suited for the deled ion of 
singularities. 

Daubechies Wavelet. Except for the Ilaar basis, all of the 
examples of orthononnal wavelet bases consist of infinitely 
supported functions. Ingrid Daubechies constructed an or- 
thononnal wavelet in which i j ■ is compactly supported. The 
way to ensure compact support for the wavelet ip is to 
choose a scaling function <|> with compact support. 




i o . 1 1 1 

-4-2 0 2 4 

I 

Fig. 6. Heal pari of tile Morlet wavelet for <"n = 5. 
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First of all, find a progression [tt^k G Z) satisfying the 
following four conditions for all integer N > 2: 

« k = 0 if k < 0 or k > 2N (23) 

V u k «k-t-2ni = 8om for all integer m (24) 
k= - x 

x 

X «k = .2 (25) 

k = - ■'- 

£ p k k m = o, Mni N-i, C263 

where |3 k = (-l) k a_ k +,. 

If N = 1, then an = a\ = 1. corresponding to the Haai- basis. 

We can find a compactly supported scaling function <p(l) 
from the above progression |u k ). The function dp(i) is one 
solution of a functional equation: 

«K0 = X «k> 2<p(2t - k). (27) 

k= - * 

It is continuous and compactly supported and satisfies 
JcpfDdl = 1 for integer N and the corresponding progression 
(<i k l. The support of <p(i) is [0.2N-1]. 

Furthermore, if (Jj, is defined as die condition 26, the function 
t|>(t) satisfying a functional etiuation 

CO 

#D = V fi k v 2cp(2t - k) (28) 

k= - x 

is compactly supported and fulfills the following: 

JIJlQ )t'"dt = 0 for all integers 0 < m £ N-l. 

cb(t), t)i(t) £ C*tW for Holder spaces C'-M where X.(N) is an 
integer parameter and the elements of C' 4S 1 are functions 
that have X(N) derivatives. 



Figs. 8 and !> show graphs of the Daubeclues scaling function 
dp and the corresponding wavelet for the value of N = 2. 

Software Tools: Khoros System 

The wavelet analysis software developed by HP Laboratories 
Japan is implemented as a toolbox in the Khoros system. 
The Khoros system is an integrated software dev elopment 
environment for information processing and visualization, 
based on the X Window System. It is distributed in the pub- 
lic domain and has been ported to the HP-UX* operating 
system. 3 

Khoros components include a visual programming language, 
code generators for extending the visual language and adding 
new application packages to the system, an interactive user 
interface editor, an interactive image display package, an 



Z T 




0 12 3 

t 

Fig. 9. The Dsubecnlos wavelet for N = 2. 
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Fig. 10, Sinusoid with i-cuistiun 
frequency- 



extensive library of image processing, numerical analysis, 
and signal processing routines, and 2D/3D plotting packages. 

Tlie Khoros system also supports the toolbox update met hod 
for new routines created by another person or developed on 
another machine. A toolbox contributed by HP Laboratories 
Japan, the HPLJ Toolbox, contains wavelet application de- 
velopment tools, image data compression utilities, and other 
utilities. 

Wavelet Analysis Examples 

The following examples illustrate the advantages of the 
time-scale resolution properties of the wavelet transform 
and a related concept, the cltirplrl transform, for the analy- 
sis of various input signals, including a delta fund ion, a step 
or box function, a differentially discontinuous function, a 
ramp Function, sinusoidal functions, a chirp signal, and a 
sum of gliding tones. 

Wavelet Analysis 

This section gives several application examples of wavelet- 
based signal analysis, including both stationary and nonsta- 
lionary signal analysis. These results were obtained with a 
Mmlel wavelet, that is, a complex sinusoid windowed with a 
Gaussian envelope, expressed as follows: 



tp(t) = e k 'exp(-±r 



(2-H 



As for the number of voices discussed earlier, we use v = 6 
in the following three examples of synthesized data analysis. 

Example 1. The first example gives the analysis of two sinu- 
soids. Fig. 10 shows a sinusoid with a single c onstant fre- 
quency, and Figs. 1 1 and 12 represent its wavelet transform. 
The horizontal axis is in time in both the magnitude picture. 
Fig. 11. and the phase picture, Fig. 12. The vertical axis is 
scale, small scale at the top. Certain features of the signal 
are evident: horizontal strips of constant magnitude, and 
vertical lines in step with the phase of the signal. 

Fig. 13 shows a sinusoid with linearly increasing frequency. 
The wavelet transform analysis results for this signal are 
shown in Figs. 14 and 15. Clearly visible is the upward slope 
corresponding to the increase of frequency. 

Example 2. The second example is the analysis of the super- 
position of two delta functions and two sinusoids, as shown 
in Fig. Id. One delta function is larger than the sinusoidal 
signals and is visible in Fig. 16, but the other is much smaller 
and does not appear. 

Figs. 17 and 18 show the wavelet transform representations. 
We can easily see the two peaks at smaller scale that corre- 
spond If) the discontinuities contained in the input signal. 

Example 3. This example shows the analysis of a sum of three 
sinusoids with different starting limes, the input signal shown 
in Fig. 1!) is nol discontinuous, but its first derivative is. 



where c is a constant value of 5 so that the function i|i(t ) 
satisfies ihe admissibility condition. 




Time Shift b 



FiK- 1 1. Magnitude of the vwivelel 

transform of a constant-frequency 

sinusoid 
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Fig. 12. Phase of the wavelel 
transform of a conslant-frequency 
sinusoid. 





Fig. 15. Phase of the wavelel 
iransfonn of a sinusoid wiih 
linearly increasing frequency. 
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Time Shift b 



Fig. 17. Magnitude of the wavelet 
transform of the sum of two delta 
func tions and two sinusoids. 




Time Shift b 



Fig. 18. I 'I iase til tin- wavelet 
transform of the sum of two delta 
ftinCtkntt and two sinusoids 




Fig. 19. Three sinusoids with 
different starting times. 
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0 



Time Shift b 



Fig. 20. Magnitude of the wavelet 
transform of three sinusoids with 
different starting times. 




Fig. 21. Phase of the wavelet 
transform of three sinusoids with 
different starting times. 



Both the frequencies and the beginnings of the components 
are very clearly visible in Hie wavelet transform pictures; 

Figs. 20 and 21. A low-frequency sinusoid stalls first, followed 
by a medium-frequency and a high-frequency sinusoid. 

Real Data Analysis. Tliis section shows the results of real data 
analysis. This data, provided by the Lake Stevens Instrument 
Division, is the transmitter turn-on data of a dual-band trans- 
ceiver that was taken at a center frequency of 1-16.52 MHz 
With the measurement span set to 3f). 0(125 kHz.. In other 
words, the data is filtered to approximately a 40-kHz band- 
width. The time interval between points is 20 lis. 

The input signal is plotted in Fig. 22. In this case, the trans- 
form was performed for the value of v = 12. and the magni- 
tude and phase of the wavelet transform are shown hi Figs. 
23 and 24, respectively. 



Chirplet Analysis 

The wavelet transform has the effect of dissecting the lime- 
scale plane into time-invariant cells with an aspect ratio 
dependent on the scale parameter. This property is impor- 
tant in spectral processing of signals but does not affect 
dynamic spectrum displays where time I is advanced by 
small increments relative to the cell width. 

The representation of signals may benefit if the cell shape is 
not held time-invariant throughout. This lime-dependent 
adjustment can be performed adaptively. Such a technique, 
called the chirplel Iriiiislbrm, has been proposed. It uses 
oblique cells adapted to the local structure, permitting 
separation of the signal components. 




Fig. 22. Transmitter ttun-00 
data. 
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Fig. 23. Mawiilinle of ft* wrvriet 
transform of transmitter tiim-on 
(lam. 



Fig. 24. Phase of Ihe wav.-ht 
transform of transmitter turn-on 
dala 



The cliiiplcl is introduced as: 



c k (t) = e 



2jt(f k l + ill") 



(30) 



where tlie c k are ihe ehirplet basis functions. f k is the fre- 
quency of Cfc <t is a measure of the "sharpness" of the ehir- 
plet. and r is a frequency drift rate parameter. The chirplcl 
transfonn is defined as: 



C(f„,t) = 



Cuft - T)s(T)dT. 



(31) 



Positive drift rale r is associated wilh upward sloping 
Oblique cells and Ihe magnitude of r is selected as needed to 
resolve Ihe slruclure of interest. 

Consider a signal formed by I wo successive gliding lones 
eac h of Ihe form: 



E(t)cos 



2 J i(f u t + i p Y J + i&t a ) 



(32) 



where E(i ) is a rising and falling modulating envelope. An 
example of the input signal is shown in Fig. 25. 

Figs. 26 and 27 represenl Ihe results of the conventional 
wavelet transform anil Ihe ehirplet transfonn, respectively. 
The wavelet transform can analyze the change of frequency 
of the input signal, but separation of Ihe signal components 
is not possible. The ehirplet transform analysis, on Ihe other 
hand, can separate Ihe two components clearly. 
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Fig. 25. Sum of two suecesslw 

ftlidins tones. 
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Time Shift b 



Fig. 26. Magnitude ul'liie wavelet 

transform of iiie sura of two 

successive gliding tones. 
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Timet 



Fig. 27. Magnitude of the ehirplet 
I ransfornt of I he sum of two 
successive gliding t ones. 
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Approaches to Verifying Operational 
Test Release Vectors 

Five techniques are employed to minimize the time to develop the test 
vectors used to test manufactured parts on an IC component tester. 

by Joy Xiao Han 



In today's competitive computer industry, the ability to 
accelerate the development process from design to manu- 
factured part in a timely manner is an important factor. At 
HP's Chelmsford systems laboratory one of the things we 
do is design and develop chips for HP 0000 Series 800 
workstations. Among the activities performed during this 
development is the generation of a series of test vectors 
called operational test release (OTR) vectors, which are 
used on component testers to verily the correctness of the 
manufactured pails. 

It typically takes six months to generate and verify opera- 
tional test release vectors. With the techniques described in 
this article we have been able to reduce the time spent 
creating these vectors to four months. 

Test Vector Development 

The final product of our test vector development process is 
a set of vectors (also called lest patterns) thai can be loaded 
onlo a tester lo verify manufactured parts. Physical defects 
thai appear on manufactured parts can be so varied that it is 
often impractical to try to detect them directly. Instead, auto- 
matic test generation, waveform Creation, and verification 
tools are employed to deal with a logical model of a physical 
defect, which is known as a fault. The most widely used 
fault model is the stnck-at fault in which the input or the 
output of a logic elenienl is stuck at logic 0 or 1. For exam- 
ple, ;m open trace, assuming positive logic, might exhibit 
itsell' as si tick at logic 0. 

Each vector that tests a typical block of application logic* 
has al teas] I wo pails. One part is made up of data and/or 
inslnictions which are applied to the Input Of the chip. The 
other part, called "expected results." is used for comparison 
with the actual output of the application logic to delect any 
faults. 

The first steps of our lest vector developmenl process are 
shown in Fig. 1. We start by using a program called ATf'ti 
(automatic tesl pattern generator) from Crosscheck Corpo- 
ration to produce a file containing the lest input patterns) 
the fault-free simulation output patients (expected results), 
and the SCan-in and scan-out** patterns for Hie lest logic. 
ATPt i uses a circuit model of the chip to determine the 
contciil of Ihe patterns produced. 

' We use ihe term application logic in this paper to teter to Ihe logic on the chip that perlorms 
the intended lunctions o' the component Ihe other logic on the chip is called test logic which 
is included on the chip tot testability. 

1 Scan-out ptttemi ate also heated as expected results 



Circuit 
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Step 1 




Step 2 



(1011 ... 1100) 



• Test Patterns 
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^ Repeal Step 2 
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Results 
Irom ATPG 



-TLTLTL . . . 



Fig. 1. The stops used to create a raw waveform data base. 

The next step in our process is lo use the Verilog hardware 
description language (Verilog HDL) lo create a behavioral and 
structural model of the target hardware. The instructions in 
the program are structured to lesi the application logic via 
special tesl pins collectively r ailed a test access port (TAP). 
The TAP provides access lo test logic circuits that are built 
IntO ■ component to lesl Ihe component itself and the inter- 
connections between components. The TAP also provides 
access lo circuits that allow control and observation of tin- 
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Overview of the Test Access Port 



Since the emergence of surface mounted devices a great deal of concern and 
discussion has gone into determining how lo test boards crammed with these 
high-density devices. In 1990 these concerns resulted in ANSI/IEEE Standard 
1 149.1-1990, Standard Access Pan and Boundary-Scan Architecture This stan- 
dard defines tesl logic that can be included nn an integrated circuit to provide 
standardized approaches lo testing the component itself or the interconnections 
between components on a printed circuit board. The standard also allows for 
observing or controlling the behavior of a component during its normal operaiion. 
The test logic allows test instructions and test data to be fed to a component, and 
upon execution of an instruction, allows the results to be read out and observed 
All instructions, test data, and results are communicated in serial format. 

The test logic defined by the standard consists of a chain of boundary-scan cells 
and test support logic, which are accessed through the TAP inputs (see Fig 1). A 
boundary-scan cell is a shift-register stage that is connected between each input 
oi output pin on an IC and the application logic to which each pin is normally 
connected (see Fig. 2) The scan cell has two states of operation One state allows 
a sequence of bits representing data and instructions to be shifted Iscanned-in) 
into a chain of scan cells, resulting in latching each cell to the desired value The 
scan-in and scan-out lines shown in Fig. 2 carry the bits from one cell to another. 
The logic specified in the standard is designed so that the serial movement of 



instruction data is not apparent to the circuits whose operation is controlled by 
the instruction 

The other state of operation for the scan cells involves testing the application 
logic The test operation involves either receiving test data from the application 
logic via the signal-in line and then latching the output, or shifting test data into 
the application logic via the signal-out line. The test logic is specified such that 
the movement of test data has no effect on the instruction present in the test 
circuitry 

After the test state is done the scan mode can be invoked again to shift out the 
latched test results for comparison with the expected results 

The clock, shift, and mode lines shown in Fig. 2 are controlled by the TAP signals 
(described belowl The TAP lines are responsible for sending the proper signal 
sequences to control the scanning or testing states. In addition, the mode line is 
controlled according to the type of pin it is connected to (e.g., input, output, 
bidirectional. Instate, etc.l 

The IEEE standard defines a minimum uf three input connections and one output 
connection (see Fig 1 1 An optional fourth input (TRST'I provides for asynchronous 
initialization of the test logic circuitry defined in the standard 



Scan Cells 



Scan Calls 





To Other 
Components 



TAP Input Signals 



Test Interconnections 
System Interconnections 



TCK = Test Clock 
TDI = Test Data In 
TDO = Test Data Out 
TMS = Test Mode Select 
TRST- = Test Reset 



Fig. 1. A simplified block diagram ot the 
test logic defined in ANSI/IEEE Standard 
1149 1-1990 surrounding application logic 



application circuits during their normal operation. The 
Specification for the TAP logic is given in IEEE Standard 
1149.1-1990. and a brief overview is provided above. Also 
included in I he Verilog HDL model are calls to a utility called 
Stds_monitor|)* which associates liming information with die bit 
patterns sent to the device tinder test. These calls will create 
a raw waveform database containing timing and pattern 
information. It is called a raw waveform database because 
during simulation runs every change on the component "s 
pins is included in the database. One or the techniques de- 
scribed below explains how this data is manipulated to 
produce a more refined waveform database. 

The third step shown in Fig. 1 involves running the Verilog-XL 
logic simulator using the Verilog HDL model created in step 

" The Std5_monuort) tuns as pan ol the Verilog-XL simulator 



2 and the patterns created in step 1 as inputs. A waveform 
database and an output pattern file are created from this 
simulation. The output patterns from the simulation are 
compared to the expected output patterns generated by the 
ATPG software. If the patterns don't match, steps 2 and 3 
are repeated until they do. If the patterns do match, we 
move on to prepare the waveform database to become our 
operational test release vectors. 

A great deal of time can be spent going back anil forth be- 
tween steps 2 and 3. The rest of this paper describes some 
techniques that I have found to be helpful in getting through 
steps 2 and 3 quickly. These techniques verify that the TAP 
circuits are functioning properly. 
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IC Componenl 



To Next Cell or TOO 
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Scan Out 



To Next Cell or TOO 
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Output 
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Cell orTDI 
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Fig. 2. The location of scan cells in relation chip I/O pins ano Die application logic The mode, clock and shift signals are derived from the TAP input signals TMS. TCK. and TRST" respectively. 
The first scan-in signal and the lasl scan-out signal correspond to TOI and TOO respectively. 



Test Clock. TCK is ihe lesi clock input that provides the clock for the test logic This 
clock is provided so lhai scan cells surrounding the application logic can be con- 
trolled independently at system clocks TCK allows shifting of test data concurrently 
with system operation (allowing online monitoring! It also ensures that test data 
can be moved to or from a chip without changing the state of the application logic 

Test Mode Select. TMS is the signal used by the TAP controller to control test 
operations. One use of TMS is to select whether the test circuitry is in Ihe test 
state or the scan state To guard against race conditions, the TMS signal like the 
TOI signal described below must be sampled on the rising edge of TCK 

Test Reset. The optional TRST* signal is included to allow for asynchronous reset 
of the TAP controller The reset signal only affects the test logic and has no impact 
on the application logic 



Test I/O Lines. TDI and TOO are the test data input and output lines respectively 
They provide for the serial movement of test data through the circuit. Data pre- 
sented at TDI is clocked into the selected register on the rising edge of TCK, while 
output data appearing a! TOO is clocked out on the falling edge of TCK To simplify 
the operation of components that are compatible with the standard, data must be 
propagated from TDI to TDO without inversion 
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Technique 1 

' licrk the scan chain* without a system clock. This step is 
mainly used to make sure that the scan chain on the cltip is 
not broken. This test works by ensuring thai whatever value 
is scanned in (SI in Rig. 2| should be exactly identical to the 
value scanned out (SQ). The scan chain is advanced by clock 
pulses. For example, a pulse from CLKA followed by a pulse 
from CLKB causes the data on SI to he propagated to SQ. SQ 
WttiS into tin* SI for the next scannalile flip flop on the scan 
chain. If the chip passes this test, we know that ihe scan logic 
is set. properly and that there is continuity in lite scan chain. 

Technique 2 

( hec k the scan chain with a system clock. This check verifies 
that Ihe combinational logic in the application logic portion Of 

A scan chain is a shift-register pain through a circuit which is typically placed there to impiove 
testability. See "dverview of the Test Access Port' on page 66 



the chip works. Usually the master clock (MCLK) is opposite 
in state to Ihe system clock (CLK) (i.e.. when CLK is on. MCLK 
is off and vice versa). The only exception to this behavior 
occurs when we execute a double-strobe test to check the 
time margin on Ihe chip. 

The opposite clock states are verified by ensuring that the 
data on the D input in Fig. 2. whic h is Ihe result of all pre- 
vious combinational logic, is inverted at MQ when CLK is low. 
On the other hand, when CLK is turned on, the inverted value 
of MQ (the exacl value of D) appears at Q. This is the same 
value we can monitor at SQ by advancing the scan chain 
with pulses from CLKA and CLKB in the correct sequence. 

Technique 3 

Check the TAP stale sequence. Since the TAP logic is basi- 
cally a state mac hine its c urrent slate is recorded in a mode 
register. I have found it necessary lo pay attention to Ihe 
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HP 



Scan Out 
Latch 




SQ 




(Scan Out) 



Fig. 2. Scattnable Hip-flop. This 

is a portion (if uur implementa- 
tion of a scan cell. Tile MCLK, Ml. 
CLKA. and CUB signals are con- 
trolled by the TAP test logic and 
are derived from Hie TAP input 
signals TMS, TRST*. atid TCK. 



previous stale of the TAP circuit by checking certain bits in 
the mode register. For example, one error that typically 
takes a long time to correct occurs when the bit in the mode 
register that controls I/O direction (PSCAN in Fig. 3 J is not 
set properly during initialization. Forgetting to set this bit 
causes TSTDEN (test data enable) to go high during a scan, 
later when data is supposed to be coming out of the chip 
(via the I/O pin ) and the tester is driving a value into the 
chip, a bus fight occurs. We want TSTDEN to be low, which 
puts the gate in tristate mode when the tester is driving a 
signal onto the pin. Anytime the wrong data is output be- 
cause of somet hing that is done or not done early in the test 
cycle, it always lakes a long lime to debug. Debugging time 
can be saved if each state (bits in the mode register) is 
closely monitored. 



The first thing we do is take the raw waveform database 
described above and use the conditioners* ALIGN and 
WINDOW to create a more refined waveform database. We 
use the ALIGN conditioner to align each signal to be edge 
triggered. The WINDOW conditioner is used to select certain 
cycles or windows within a cycle during which output data 
is valid, which results in monitoring pins only at the limes 
we care about. The next step is to verify that the windowed 
data is okay. This involves the same process we went 
through in steps 2 and 3 of Fig. 1. If everything is okay, the 
waveform database is converted to OTR vectors to run on 
the tester. 

' Conditioners are functions that piuvide a way to modify waveform data generated via 
Stds.monitor. The ALIGN and WINDOW conditioners come from TSSI Inc. 



Technique 4 

Check the value of each pin before each system clock. One 
bug that occurs frequently is that test vectors will run 
smoothly dining simulation, but cause bus fights when they 
are run on the tester. From Fig. 3 we can see that if BUSIN 
and the tester drive an identical value onto the I/< > pin at the 
same time, a problem occurs that can only be caught by the 
tester and not by simulation. This problem can be eliminated 
if we stop the simulation before each system clock and 
make sure that the I/O pin is driven by either BUSIN when the 
pin acts as an output (i.e., the pins drive the values to the 
BUSOUT), or by the tester when the pin ads as an input, but 
not both at one time. This task can be easily accomplished 
by using the Verilog-XL command Sshowvars. 



PSCAN 




From 
• Mode 
Register 



BUSIN 



>• BUSOUT 



Technique 5 

Verify - that the process of creating the operational test release 
(OTR) vectors for the tester is correct. Fig. 4 shows the addi- 
tional steps we lake to create and verify the OTR vectors. 



TEST0EN = 0 when TESTER DRIVING Is Sending Input to I/O Pin 
= 1 when BUSIN Is Sending Output to I/O Pin 

Fig. 3. A simplified diagram of the circuitry around an I/O pitt. 
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Tke contents of 
the refined waveform 
database bee— » 
the OTR Vectors. 



Fig. 4. Thf- final steps in creating th«- OTR vectors. 
Conclusion 

These five techniques have proven to be a success in the 
( helmsford systems lab by shortening the rime it takes us to 
produce final test vectors. These techniques can also be 
applied to non-ATPG OTR v ectors, since we can create vec- 
tors manually to meet different needs and put them into 
ATPG format. We characterized the entire analog circuitry 
embedded in one chip by controlling the proper bits on the 
scan chain. 
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Estimating the Value of Inspections 
and Early Testing for Software Projects 

A return-on-investment model is developed and applied to a typical 
software project to show the value of doing inspections and unit and 
module testing to reduce software defects. 

by Louis A. Franz and Jonathan C. Shin 



The software inspection process has become an important 
pan of the software development cycle, l&w* and has been 
used with varying levels of success within Hewlett-Packard- 4 * 6 
One of the main reasons for its success is that detecting 
defects early has a big impact on reducing the cost of dealing 
with software defects later in the development cycle. One 
IIP entity used metrics data from several software projects 
and an industry profit and loss model to show the high cost 
pf rinding and fixing defects late in the development cycle 
and during postrelease/' 

This paper describes ihe methods we have used lo integrate 
inspections and prerelease testing into the development of an 
information technology software project. The metrics col- 
lected and the tools we used to collect t lie metrics data on 
this project are described. Finally, we describe an approach 
to using the metrics data collected during inspections and 



testing to estimate (he value (return on investment) of in- 
vesting time and effort in early defect detection activities. 

Background 

The sales and inventory tracking (SIT) project evolved from 
separate initiatives by several different groups in HP. These 
initiatives had different objectives, but all relied on elements 
of the same data: computer dealer sales and inventory levels 
of HP products. To simplify (he collection, processing, and 
storage of (his daia, il was decided to create a centralized 
system to house the data. All the applications that would 
need to use this information could access the central SIT 
system database. Fig. 1 shows the four major modules that 
make up the SIT system and the major data stores accessed 
by the system. These modules will be referenced throughout 
this paper. Table I provides a summary of the major attributes 
of the system. 









Mair 
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Intom 
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Maintain 
Product 
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Fig. 1. The major components of 
the sales and inventory tracking 

(SIT) system. 
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Table I 

Summary of the Sales and Inventory Tracking System 



System type 
Hardware platform 

Language 
DBMS 

Data communications 
(used for the electronic 
transfer of data between 
the dealer and HP) 



Data access and 
manipulation tools 

Code 



Batch 

HP 3000 Series 980 running the 
MPE/XL operating system 

COBOL 

HP AllBase/SQL (relational) 

Electronic Data Interchange 
(EDI) ANSI standard transac- 
tion sets (file formats): 
867 produc t transfer and 

resale report 
846 Inventory inquiry and 
advice 

Cognos, PowerHouse (Quiz), 
Supertool. KSAM. and VPLl'S 

2SK total lines of source code 
(13.fi KNCSS)* 



" KNCSS = Thousands of noncomment source statements 

We used the traditional HP software life cycle for our devel- 
opment process. The basic steps of this process include: 

• Investigation 

• Design 

• Const met ion and Testing 

• Implementation and Release 

• Postimplementation Review, 

The inspection and prerelease testing discussed in this paper 
occurred dining the design, construction, and testing phases. 

Inspection Process and Inspection Metrics 

The objectives of the inspection process are to find errors 
early in the development cycle, check for consistency with 
coding standards, and ensure supportability of the final 
code. During the course of conducting inspections for the 
SIT project, we modified the IIP inspection process to meet 

our specific needs. Table II compares the recommended ill' 
inspection process with our modified process. 

Step :i was changed to Issue and Question Logging because 
we found that inspectors often only had questions about the 
document under inspection, and authors tended to feel more 
comfortable with the term issue rather Chan defect. The 

Table II 

Comparison of Inspection Processes 



Step Our Inspection Process 



HP Inspection Process 



0 


Planning 


Planning 


1 


Kickoff 


Kickoff 


2 


Preparation 


Preparation 


3 


Issue and Question Logging 


Detect Logging 


4 


Cause Brainstorming 


( 'ause Brainstorming 


5 


Question and Answer 


Rework 


0 


Rework 


Follow-up 


7 


Follow-up 





term defect seemed to put die author on the defensive and 
severely limited the effec t iveness of the inspection process. 

The Question and Answer step was added because inspectors 
often had questions or wanted to discuss specific issues 
during the Issue and Question Logging session. These ques- 
tions defocused the insjiection and caused the process to 
take longer 

In the Planning step the author and the moderator plan the 
inspection, including the inspection goal, the composition of 
the inspection team, and the meeting time. The Kickoff step 
is used for training new inspectors, assigning the roles to the 
inspection team members, distributing inspection materials, 
and emphasizing the main focus of the inspection process. 
During the Preparation step, inspectors independently go 
through the inspection materials and identify as many defects 
as possible. In the Cause Brainstorming step, inspection team 
members brainstorm ideas about what kind of global issues 
might have caused the defects and submit suggestions on 
how to resolve these issues. During the Rework step, the 
author addresses or fixes every issue that was logged during 
step 3. Finally, in the Follow-up step, the moderator works 
with the author to determine whether every issue was 
addressed or fixed. 

Along with the modified process, a one-page inspection 
process overview was generated as the training reference 
material for the project team. This overview was a very con- 
venient and useful guideline for the project team because it 
helped to remind the leant what they were supposed to do 
for each inspec tion. 

Deciding What to Inspect 

Because of time and resource constraints, not all of the 
project's 13 source programs and 29 job streams could be 
inspected. The project team decided to use the risk assess- 
ment done for the master test plan, which uses the opera- 
tional importance and complexity of a module as a basis for 
deciding which programs and job streams to inspect. The risk 
assessment used for the master lesi plan is described later. 
Fig. 2 shows the results of this selection process in terms of 
inspection c overage and relative level of complexity of the 
programs and job streams. 

inspection Metrics 

Three forms were used to collect inspection metrics: the 
inspection issue log. I he inspection summary form, and the 
inspection data suuimarv and analysis form. Fig. 3 shows an 
inspection log and ;ui inspection summary form. 



Modules 


Ten Plan 

and 
Test Script 
Inspected 


Percent of 
Programs 
Inspected 


Percent ol 
Job Streams 
IJCU 
Inspected 


Relative 
Complexity 


1.0 


Ves 


67% 


100% 


Medium 


2.0' 


No 


100% 


100% 


tow 


mm 


Yes 


60% 


33.3% 


Medium 


mm 


Yes 


100% 


100% 


High 



* This module consisted ol only one JCL and one program. 

Fig. 2. Inspection coverage for the major modules In the SIT system 
basfil mi (In- criteria useil in the master plan. 
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Inspection Summary 



Inspection Issue Log 



Page of 

Document Insnected 


Inspection Dale 




Paged 
Line* 


Issue 
Description 


Type 


Severity 


Resolution 




























Type: (SI Specilication 




IDU Design Logic 


{□) Data 




(M) Miscommunication 


ISO) Standards Deviation 


(OVI Oversight 


|R) Resources 




(01 Others 




Severity: (C) Critical 




INI Non-Critical 


(E) Enhancement 









(al 



Inspection Date: 

Kickofl Meeting; 

System or Project Name:_ 
Document Inspected: 
Preparation Time: 



Start Time: . 
Finish Time; 



Moderator 



Reader 



Author 



Total 



Inspector 



liib|iecIoi 



Inspector 



Type of Inspection: 
(Circle the Type) 



Prototype 
Test Plan 
Other 

Pages 



Investigation 
Coding 
Documentation 
Approximate Document Pages 
or Program Lines Inspected: 
Number ol Critical Issues 10 
Specifications 
Design Logic 
Data 

Standards Deviation 
Miscommunication 
Oversight 
Resources 
Other 

Total: 

Number of Enhancements 1^1 

How many times was this document inspected? 
How many times was this document postponed? 

Why was it postponed? 
How many peopie were asked to participate in the 

inspection but refused? 
Total time author spent to fix or address all defects: 
Total time moderator spent to follow up with author: 



ES 

Installation 



IS 

Release 



IS ) 

lot ) 

_iPJ 
ISP ) 
IM) 

jgyi 
_!Ri 

(0) 



Number of Noncritical Issues (N) 
Specifications 
Design Logic 
Data 

Standards Deviation 

Miscommunication 

Oversight 

Resources 

Other 



NCSS 



IS) 



(DL) 



(SDI 



IM) 



iOV; 



(Rl 



10) 



Total: 



lb) 



Fig. 3. (a) Inspection issue lug. (b) Inspection summary form. 



The inspect ion issue log is used for logging the issues ob- 
served by I he inspectors during the Issue and Question 
Logging session. The inspection summary describes the doc- 
ument inspected, die inspector's preparation lime, the type 
of inspection , the number of pages and lines inspected, the 
number and types of defects identified, and the total lime 
used to fix or address all the defects. The inspection dafa 
summary and analysis form is a spreadsheet that was used 
to collect the data entries required to calculate inspection 
efficiency, inspection effectiveness, total time saved, mid the 
retum-on-investment value (described later). Table III lists 
the data collected in the data summary anil analysis form for 
each item inspected. 

We selected four key inspection metrics to measure our in- 
spection effort: number of critical defects found and fixed, 
number of noncritical defects found and fixed, total time used 
by inspections, and lotal time saved by inspections. 

Testing Process 

Our testing process included test planning, unit testing, 
module testing, and system testing. Test planning involved 
creating a master test plan and doing a risk assessment to 
determine where to focus our testing time. 

Master Test Plan. A master test plan was created during the 
design phase when the test strategy for the project was out- 
lined (Fig. 4). The master test plan included the test plan 



design and the type of tests to be performed. For design 
purposes, the system was divided into logical modules with 
each module performing a specific function (see Fig. I). The 
test design was also oriented around this division. 




Unit Test Case 
Worksheet 



Master 
Test Plan 



Module 
Test Plan 



Module 
Test Script 



Module 
Test Report 



Fig. 4. Master test plan organization. 



System 
Test Plan 



System 
Test Script 




System 
Test Report 
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Metric 

Inspection time 

Defects 

Documentation type 



Table III 

Inspection Summary and Analysis Data 

Units or Source of Data 



Preparation and meeting time in 
hours 

Number of critical and noncritica] 
defects 

Code, requirements and design 
specifications, manuals, test 
plans, job streams ( JC'L), and 
other documents 



Size of document 

Amount inspected 

Preparation rate 

Logging rate 

Moderator follow -up 
time 

Time to fix a defect Hours 
Total time used 

Time saved on critical * 
defects 

Time saved on non- 
critical defects 

Total time saved 

Return on investment * 



KNCSS for code and number of 
pages for other documents 

KNCSS or number of pages 
inspected 

= (number of pages) x (number of 
people j/preparat ion time 

= (critical + noncritical defects)/ 
("hours/number of people) 

Hours 



= inspection time + time to fix + 
follow-up time 



Defined later in this art icle 

The primary and secondary features to be tested were also 
included in the master test plan. The primary features were 
tested against the product specifications and the accuracy 
of the dala output. Secondarily, testing was performed to 
ensure optimum speed and efficiency, ease of use ( user 
interface), and system supportaliility. 

Risk Assessment. A risk analysis was performed to assess the 
relative risk associated with each module and its compo- 
nents. This risk analysis was used to help drive the schedule 
and lower-level unit and integrated tests. Two factors were 
used in assessing risk: operational importance to overall 
system functionality and technical difficulty and complexity. 
Each module was divided into submodules and rated against 
each risk factor. For example, the proper execut ion of the 
logic in submodule 4.2 was critical to the success of the sys- 
tem as a whole, while submodule 1.4 merely supplied addi- 
tional reference dala to the database. Accordingly, module 
4.2 received a higher operational importance rating. Simi- 
larly, submodnle 4.2 also received a higher complexity rating 
because Of the complexity of the coding task it entailed. 
Each rating was based on a scale of one to five with one 
being the lowest rating and five being the highest raling. 
Ratings for each risk factor were then combined to get an 
overall risk rating for each submodule (Fig. 5). 



Module 


Submodule 


Operational 
Importance 


Technical 
Difficulty 


Overall Risk 
Rating 


1.0 


1.1 


5 


1 


t 




U 


5 


3 


8 




13 


5 


3 


8 




1.4 


1 


1 


2 




13 


4 


3 


7 




tJt 


3 


2 


S 


2.0 


11 


5 


2 


7 




22 


5 


3 


■ 


30 


3.1 


5 


4 


3 




32 


5 


2 


7 




33 


3 


2 


5 




3 


4 


5 


2 


7 




35 


4 


5 


9 




3.6 


1 


1 


2 


4.0 


41 


5 


3 


8 




4.2 


5 


5 


10 




4 


3 


5 


4 


9 




4.4 


5 


3 


8 




4 


5 


3 


2 


5 




4.6 


2 


4 


6 




4.7 


1 


3 


4 



Fi«. 5. Risk ratings by submodule. 

Unit Testing. Unit testing, as in most software projects, was 
performed for all programs and job streams. For the purpose 
of this project] each individual program and job stream was 
considered a unit. Since programs were often embedded in 
job st reams, program unit tests were often synchronized 
with job stream unit tests to conserve time and effort. 

Because of the small size of the project team, almost all 
tests were performed by the program or job stream author. 
To minimize the impact of tliis shortcoming, a simple testing 
review process was established. A series of standard forms 
were created to document each lest and facilitate review by 
the designer, users, and the project lead at different points 
in the unit testing process (see Fig. fi). 

Module Testing. An integrated test of all programs and job 
streams within each module was conducted to test the over- 
all Functionality of each of the four system modules. Since 
each program or job stream had already been tested during 
unit testing, the primary focus of module testing was on ver- 
ifying that the units all functioned together properly and that 
the desired end result of the modules processing was 
achieved. 

A brief integrated CeSt plan document was created for each 
(nodule, This test plan listed Ihe features to be tested and 
outlined the approach to be used. In addition, completion 
criteria, lest deliverables and required resources were 
documented ( Fig. 7). 

Detailed lesl scripts were used lo facilitate each module lest 
and make il easy to duplicate or renin a particular lest. Each 
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Unit Test Case Worksheet 



Module Unit: 4.2 




Program/Screen/Job Name: SIT4023S 


VALID Input Conditions 


INVALID Input Conditions 


Loc hdr.id code<>9 


No transaction header 


Ouantity qualified = 14, 17, 76 


ANSI code <> 867, 846 




Tx_count= spaces 















Unit Test Script 



Module Unit: 4.3 

Program/Screen/Job Name: SIT 403IS 
Script «: 

Procedure 



(1) Set file equations 



(2) Run program, parm = c 



(3) Verify file layout matches 



Resources needed 



Programs: GETPROD 



Screens: — 



Database: SITDB, PRIME 



SITDB Tables: Outlets, ChanneLproducts 



Others 



Unit Test Case 



Module Unit: 4.2 

Program/Screen/Job Name: SIT4020J 

Script*: 

Pass:@)/ No 

Case Descrip tion 



Date Inspected: 5/4/92 



Verify that locations with missing elements are reported. 



Input Conditions 



Outlets table "business_name" blank 0I0 = 0671100920 



End-user table "company" blank 010 = 06711001 IS 



Output Conditions 



OID = 0671100920 appears on report 



0ID = 0671 1001 1 S appears on report 



Special Requirements 



Use test file TST40207 TEST.SIT 



Fig. 6. Unit lest toons. 

Feature to Be Tested 

• Module processes run correctly when run in production order 

• Module processes run correctly with actual production data 

• All programs, JCLs, screens pass data to next process on timely basis 
Approach 

• Set up production test environment 

• Stream JCLs, run programs, and execute entry screens in production order 

• Use production data 

• Verify subsets of key table data after each process 
Completion Criteria 

• All programs, JCLs, screens run without error or abort 

• End result of process is correct data loaded into Product mix, Product exhibit. 
Channel products. Customer. Products, and Customer , Exhibits Tables 

Test Deliverables 

• Test script 

• Test summary report 
Resources 

. Staff - Lou, Shripad, Jill 

• Environment 

Jupiter - SIT account 

BliU - Patsy DB IPATSY*t.PATDTA.MAS):Mode 5 
- Prime DB IPRIME3*#.PR3DTA.MAS):Mode 6 

Fig. 7. A portion nf an Integrated (est plan. 



tesl scrip! document included a listing of the resources 
needed for the test, such as supporting databases. SIT data- 
base tables, files, file equations, programs, and a step-by- 
step procedure for executing the test. Where appropriate, 
specific data to be entered into the system was included in 
the procedure. Also included were the expected results of 
each tesl slep and the overall test. 

Once the integrated module tests had been completed suc- 
cessfully (often this took several iterations), a report detail- 
ing the lest results was created. The integrated test report 
documented the number of times the test was run, verified 
that the completion criteria were met, listed the number of 
critical and noncritical defects detected, and verified that 
each defect had been fixed. 

System Testing. System testing was conducted in tandem 
with a pilot test at an HP dealer. Initial values were entered 
for the general-purpose database tables and for die dealer 
inv olved in the pilot test. Production schedules were used to 
control the job streaming that executed the system. 

Testing Metrics. Two kinds of metrics were selected lo mea- 
sure our testing effort: total number of critical defects and 
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total testing lime for each test phase. Table IV summarizes 
our test metrics for unit and module testing. One critical 
defect was found during system testing and the total system 
test time was 19 hours. 



Table IV 
Testing Metrics 

Module Size* Unit Test Module Test 







Tc 


N e 


IATTI C 


Tc 


Ne 


<ATT) C 


1.0 


4489 


TJ 


4 


18.25 


41 


7 


5.86 


2.0 


639 


26 


0 


0 


«* 


** 


** 


3.0 


:r>u; 


31.5 


3 


10.5 


46 


2 


5.11 


4.0 


3738 


35 


21 


1.67 


36 


13 


2.77 



Noncomment source statements (NCSSI 
Not applicable 

7 C = Total lestinrj time tor critical Defects in hours 
N ( = Total number ol critical defects 
(ATTic = Average testing time per critical delect = T t /N, 
(ATI I, is defined as zero when N- is zero 

Return-on-Investment Model 

It is now generally accepted that inspections can help soft- 
ware projects find defects early in the development cycle. 
Similarly, the main purpose of unit and module testing is to 
detect defec ts before system or pilot testing. Questions that 
i ill ci i come up regarding these defect finding efforts include 
how much project time they will consume, how effective 
they are. and how we can measure their value. Most of 
these issues have been addressed in different ways in the 
literature.'' 1 ' 

In this section we present a retuni-on-investmenl ( R< >I ) 
model we used to measure the value of inspections and 
early testing in terms of time saved (and early to market). 
The whole idea behind this kind of measurement is thai ii 
should lake longer to find and fix a defect at system test 
than il does to find the same defect during inspection or unit 
testing. This means thai for even defect found during an 
inspection oral an earlier stage of the testing phase, there 
should be a lime savings realized al Ihe system lesi phase. 

First we define the Prerelease H< »l as: 

Prerelease ROI = 

Total Time Saved / Total Time Used ( 1 ) 

where: 

Total Time Saved = Total Time Saved by Inspection + 
Total Time Saved by Unit and Module Testing 

and 

Total Time Used = Total Time Used by Inspection + 
Total Time Used by I 'nil and Module Testing 

We calculate the individual Hi >I for inspection and testing, 
respectively, as follows: 

Inspection ROI = Total Time Saved 

by Inspection/ Total Time I'sed by Inspection (2) 



Testing ROI = Total Time Saved by Unit 

and Module Testing Total Time Used 

by I nit and Module Testing. (3) 

We wanted to measure not only how much time was being 
spent on inspection and testing but also how much time was 
being saved as a result of the defects found during inspec- 
tions and unit and module testing. 

The time used during an inspection includes the sum of the 
total inspection time spent by each team member, the time 
spent by the author on fixing the defects, and the time spent 
by the moderator following up on defect resolution with the 
author. 

For inspections, we defined the total lime saved and t he 
total time used as: 

Total Time Saved by Inspection = Time Saved on 
Critical Defects + Time Saved on Noncritical Defects 

Total Time I sed by Inspection = Inspection Time + 
Time to Fix and Follow up for Defect Resolution 

where Ihe critical defects are defects that affect function- 
ality and performance and noncritical defects are all other 
defects. 

The time spent finding and fixing a critical defect at system 
test is called BBT (black box testing time). Therefore, for 
every critical defect found before system test, the total time 
saved can be calculated as follows: 

Time Saved on C ritical Defects = BBT x Number of 
Critical Defects - Total Time Used. 

The model we used to measure noncritical defects is based 
OH Che assumption that noncritical defects could be found 
by inspection but would not be delected by testing. The non- 
critical defects will become suppt inability issues after man- 
ufacturing release. We defined a new variable r ailed MTTR* 
(mean lotal lime to rework) to measure the time spent on 
noncritical defects. 

MTTR a Time to Find Defect + Time to Fix Defect + 
Time to Release to Production. 

Thus. 

Time Saved on Noncritical Defects = MTTR x Number 
of Noncritical Defects. 

For lesling metrics we wanted I" measure not only how 
much time was being spent on unit anil module testing, bni 
also hOW much lime was being saved as a result of the de- 
fects found (luring these tests. Thus, we defined the total 
time saved and total lime used for testing as: 

Total Time Saved = Time Saved on Critical Defects 

Total Time Used = Time to Design and Build a Test + 
Time to Execute + Time to Find ;md Fix a Defect. 



• We used an average timo ol 6 hours lor MTTR m oui calculations 
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Tfifi defect data ;unl lime data for our sates and inventory 
tracking project are summarized in Tables V and VI. 

Table V 

Defect Summary for the SIT Project 

During During Total 
Inspection Testing Prerelease 
Defects 



Number of Critic al De- 
fects Found and Fixed 

Number of Noncritical 
Defects Found and 
Fixed 



12 



:>1 



78 



Inspection 

Testing 

Prerelease 
Total 



Total Time 
Used (hours) 

90 

310 

400 



Total Time 
Saved (hours) 

708 

710 

1418 



Return on 
Investment (%) 

787 

229 

355 



Results 

Fig. 8 shows that with the exception of module SIT4.0 the 
average testing time per critical defect decreased from unit 
test to module lest for the system's major modules. The rea- 
son that it took 19 hours per critical defect at system test is 
mainly the time it took to fold and fix one defect that was 
overlooked during inspection. Had the project team not over- 
looked one particular issue related to product structure that 
resulted in this defect, the average testing lime per critical 
defect at system test would have been significantly lower. 

Module STT4.0 went through the most thorough inspection 
including a design inspection since it is the most complex of 
the four modules. We believe our efforts paid off because it 
took less time at unit test and module lest in terms of aver- 
age testing time per critical defect for module SIT4.0 than 
for the other three modules. 
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Willi the code size equal to 13.6 KNCSS, prerelease defect 
density = 141/13.6 = 10.4 derects/KNCSS. 

I 'sing the model described above, we can calculate the ROI 
values shown in Table VI. 

Total Time Saved by Inspection = (20 hours x 12) + 
(6 hours x 78) - 90 hours = 708 hours** 

Total Time Saved by Testing = 20 hours x 51 - 310 = 710 
hours* 

From equations t, 2, and 3: 

ROI for Inspections = 708 / 90 = 787% 
ROI for Testing = 710 / 310 = 229% 
Prerelease Total ROI = 1418 / 400 = 355%. 

Table VI 

Time Data and Return on Investment Results 



Unit Module Syslem 

SIT1.0O SIT2.0A SIT3.0O SIT4.0a System <r 

Fi«. 8. Testing time by test phase and. nodule 

Fig. 9 is a plot of the ROI column in Table VI. It shows that 
inspections have resulted in more than three times the ROI 
of testing. This reinforces the notion I hat a great deal of 
money and time can be saved by folding defects early in the 
software development cycle. 

Lessons Learned 

The inspection and testing processes we used for the SIT 
project are not very different from other sofiware projects 
in IIP. However, we did put more emphasis on early defect 
detect ion and collected a lot of metrics. The following are 
some of the lessons we learned from our efforts during this 
project. 

Project Management. Some of the lessons we learned about 
project management include: 

Selling aside lime for inspections and thorough testing does 
pay off in the long run. Management approval may be diffi- 
cult to get, especially when under intense time pressure. 
One should get commitment to delivering a quality product, 
then present inspections and testing as part of delivering on 
this commitment. 

Keep high-level test plans short and simple while still pro- 
viding enough direct ion for the lower-level plans. By keep- 
ing these plans short and simple, time will be saved and the 
project team can still get adequate direction. 
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Fig. 9. Relative imparl of Inspections and Testing. 



' The rime to find and fix a cnncal defect during system test at HP ranges Irom 4 id 20 hours. 
We used 20 hours in ou< ROI calculations. 
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Adequate follow-up to inspection and testing activities is 
important to make sure all issues are resolved. The inspec- 
tion log. testing error logs, and integration test reports 
helped the project lead keep up on the status of each issue 
and ensure thai each issue was resolved. 
Establish coding standards at the beginning so that mini- 
mal time is spent during code inspections questioning 
points of style The focus of code inspections should be 
code functionality. 

Inspection. Since the inspection process is the most impor- 
tani tool for defect-free software, many adjustments were 
made here. 

Attitude is the key to effective inspections. No one writes 
error-free code, but many people think they do. Authors 
must realize that (hey make mistakes and take the attitude 
thai i hey want inspectors to find these errors. The inspec- 
tors, on the other hand, can destroy the whole process by 
being too critical. The inspectors must keep the author's ego 
intact by remaining constructive. Perhaps the best way to 
keep people's attitudes in line is 10 make sure they know 
that they may be an inspector now. but at a later date, their 
role and the author's will be reversed. For diis reason, im- 
plementing an inspection process for most or all of a proj- 
ect's code is likely to be much more effective than random 
inspection of a few programs. 

No managers should be involved in the inspection of code. 
Having a manager present tends to put the author on the 
defensive. Also, depending on the person, the inspector ei- 
ther goes on the offensive or withdraws from the process 
entirely. 

In addition to finding defects (or "issues"), which helps to 
save testing and rework time, the inspection process has 
other, more intangible, benefits: 

6 Increased teamwork. Inspections provide an excellent 
fontm for the team to see each other's strengths and weak- 
nesses and gain a new respect for each Other's unique abi- 
lities. By adding the question and answer session to the 
inspection process. we provided a forum for the team to 
discuss issues and creatively solve them together. 

0 Support team education. Including members of the team 
that would eventually support the SIT system allowed 
these people to become familiar with the system and con- 
fident that it would be supportable. 

Testing. The lessons learned from unit and module testing 
include the need for expanded participation in testing and 
the value of test Scripts. 

Drat testing. On small project teams it is difficult to coordi- 
nate testing so that someone other than the author tests each 



unit. Establishing a process that includes the designer, other 
pmgraniiners. and users helps tremendously towards ensur- 
ing full test case coverage. 

• Module testing. Integration test scripts are invaluable. The 
effort expended to create the scripts for the SIT project was 
significant, especially the first one. However, the reward, 
in terms of time saved and rework, more than justified the 
effort. Furthermore, these scripts have been very useful to 
the support team for performing regression testing when 
the programs or job streams are modified. 

Success Factors. The SIT product was released to production 
in early March 1992. Since that time the product has been 
relatively defect-free. In reviewing what has been done, we 
observed some key factors that contributed to our success. 
These success factors can be summarized as following: 

• Strong management support. We had very strong manage- 
ment support for the inspection and testing process and the 
time commitment involved. This was the most important and 
critical success factor for the implementation of inspections 
and metrics collection. 

• Team acceptanc e. The SIT project team accepted the quality 
concept. We agreed on our quality goals and understood 
how the inspection and testing processes would help us to 
achieve those goals. 

• Focus. The SIT project was selected as the pilot project to 
implement the inspection process. Our initial focus was on 
code inspection. After the project team felt comfortable 
with doing inspections, other documents such as test 
Scripts and test plans were also inspected. 
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Clock Design and Measurement Issues 
in Pentium Systems 



Design difficulties in producing a statistically stable 66-MHz Pentium 
system are reviewed. The information is pertinent to many other new, 
high-speed processors as well. A new, more informed approach to 
designing well-timed systems in this performance class is proposed. 
Measurements that support this approach are examined, particularly 
those made with the HP 81 33A pulse generator. 

by Michael K. Williams and Andreas M.R. Pfaff 



Clock rales in all classes of computational systems, from 
PCs to supercomputers, have been escalating exponentially 
for years. Computational systems formerly considered sim- 
pler have come to run at Speeds thai were previously found 
only in more complex and aggressive systems. Before tliis 
happened, systems at the simpler end of this spectrum (PCs 
and workstations) operated at clock rales Chat don't present 
very difficult clock distribution and reception problems. 

Recenl Introductions of new processor types have given PC 
and workstation system designers new chips and chipsets 
that enahle syslein designs that deliver much higher levels 
of performance. 1 Most of these devices employ internal 
structures that come directly from the world of mainframes 
and supercomputers: pipelining, 64-bil dala buses, on-board 
noaiing-point units, instruction prefetching, and sophisti- 
cated caching schemes. Many of these processors are sum- 
marized in Table I. These new device families include Intel's 
Pentium processor, Digital's Alpha, the Apple/TBM/Motorola 
PowerPC, and others. These ICs have clock rates that range 
from lens lo hundreds of MHz. Some are expected eventually 
to exceed 1 GHz. 

Table I 

Some New Processor Types and their Clock Rates 
Manufacturer Processor Clock Rate 

Intel Pentium (50 and 66 MHz 

Intel P54C 99 MHz 

Intel 486 66 and 99 MHz 

AppkvTBM/Motorola PowerPC 80 MHz 

Digital Equipment Corp. Alpha > 100 MHz 

MIPS R4400SC 150 MHz 

Willi all of the sophisticated Internal slructures and faster 
operating speeds comes a price to be paid by the design 
team. Specifically, successful system design al these speeds 
requires very careful consideration of many mechanisms, 
such as timing and pulse fidelity, that are unimportant al 
lower speeds (16 to 33 MHz). 



Pulse fidelity, sometimes referred to as signal integrity, is 
thai part of high-speed digital design that is concerned with 
managing the analog effects that prevent signals from being 
reliably recognized al their destinations. This includes ensur- 
ing that edges ar rive al I heir loads with proper edge speeds 
and proper shapes, and control ling the various types of 
noise (crosstalk, EMI. reflections, ground bounce, etc.) that 
call cause unreliable or false triggering. The extent to which 
Ihese issues are important has increased dramatically in PC 
and workstation designs. Wider buses and faster clocks and 
edges (higher waveform spectral content ) are the primary 
sources of these problems. The classic discussion of all of 
Ihese analog effects can be found in reference 2. 

Timing, or clock distribution and reception, is the other criti- 
cal facet of design in Ihese faster systems, and is possibly 
the most significant and least well-understood aspect of the 
design. Timing environment design is the process of specify- 
ing how the clock is to be distributed and received through- 
out the system such that the state architecture is reliably 
synchronized. Reliable means that synchronization is guar- 
anteed on every cycle of every copy of the design thai is 
manufactured, despite the presence of a variety of statistical 
tplerancing mechanisms (skew, jitter, etc.) which reduce the 
precision wit h which (he clock can be delivered. These fol- 
erancing mechanisms are described in detail on page 70. 
When reliable synchronization is ensured by sound design 
practices, the design is said to be statistically stable. 

The question of exactly how to ensure ibis statistical stability 
is one that each design team must face as they adopt these 
new devices into their designs. Success at answering this 
question brings with il higher yields, fewer design turns, and 
the elimination of extremely subtle liming failures. Methods 
for doing this, while relatively new lo designs al the work- 
station and PC level, have been commonplace in the design of 
higher capability systems (mainframes and supercomputers) 
for many years. A descriptive term for the approach thai is 
common to all of these methods is informed design. 
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Fig. 1. Tuning environment design process. Design-specific and/or 
unrated parametric information must be Incorporated into the 
engineering decision making process from the outset. 

Two results arc produced by an informed approach to the 
design of a liming environment. The obvious one is a .specifi- 
cation of a clock distribution scheme. Equally important, 
however, is a detailed knowledge of the tolerance on the 
arrival time of any clock waveform emerging from any out- 
put of any copy of that network, on any cycle of its opera- 
tion. This knowledge, that is. the tolerance budget, is used 
by the timing verification software to determine if the rest of 
the system is correctly timed, t )hviously the quality of this 
determination is a function of the quality of the tolerance 
budget. Informed design, as it applies to timing, can be 
viewed as the practice of ensuring that all of the mecha- 
nisms I hat contribute to the overall tolerancing of the clock 
have been accurately assessed. 

Measurement is used to characterize devices and printed 
circuit board processes to see how they tolerance. This 
device-level tolerance data is used in compute the overall 
tolerance on the system clock. And this system-level toler- 
ance is used within the timing verifier to ensure the creation 
of a statistically stable system. Fig. 1 illustrates where device- 
level parametric data fits into the overall decision making 
process. 

In this article we examine some of the difficulties a designer 
will encounter in specifying, analyzing, and verifying a liming 
scheme lot a 60-MHz Pentium system. This falls in the lower 
speed range for the new round of processors. However, 
ultralight liming specifications coupled with the currently 
available implementation technologies (clock buffers, 
printed circuit hoards, etc.) make 66-MHz Pentium systems 
among the niosi difficult from a timing environment design 

perS] tive. We will see. for example, that the tuning within 

the ('FT complex (processor, cache controller, and cache 
RA.Ms) is v ery sensitive to cluck jitter. This sensitivity, and 




Clock to any 
Cache SRAM 



Fig. 2. The difference in arrival time between either the Pentium 
clock or the cache controller Clock and the clock arriving at any 
SRAM must he less than 700 ps itt every' system on every cycle. 

others, make 66-MHz systems ideal for the informed design 
approach. Furthermore, the issues and methods presented 
are general and extend to other processor types as well. 

Pentium Characteristics and Requirements 

An understanding of the difficulties of distributing a clock 
within a Pentium design must begin with an understanding 
of Pentium timing requirements. Our discussion of this as- 
pect of the design will be in summary form, and the reader is 
referred to the Intel documentation*" for a more complete 
discussion of requirements. Also, reference 7 discusses both 
the requirements and the various design decisions in much 
deeper detail than can be dune here. 

A variety of system configurations are supported by the 
Pentium processor. The clock rate can be either 60 or 66 
MHz. The system can use either no second-level caching, or 
it can have 256K-byte or512K-byte cache memories. Systems 
with 256K-byte caches can operate at either cluck rale, while 
512K-byte systems are limited to 6(1 MHz. A "typical" Pentium 
design is expected to operate at 66 MHz and have a 2">6K-byte 
second-level cache. For such systems, there are 12 clock 
loads within the CPU complex. Depending upon how the 
rest of the system is designed, the total number of clock 
loads will typically be in the range of 15 to 20. although in 
some server systems, this number can range an order of 
magnitude higher. 

The Pentium specification dictates that the arrival times of 
the clock at the processor and at the cache controller never 
differ by more than 200 ps. It also stales that the difference 
in arrival times between the processor and any cache mem- 
ory, and the cache controller and any cache memory, can 
never exceed 700 ps (Fig. 2). These tolerance specifications 
must be met at 0.8, 1.5. and 2.0 volts. In any design, there 
will be Other tolerance requirements that slate how much 
difference in arrival time is permitted between clocks at 
loads wfthhi the CPI ' complex and clocks at loads external 
to it (external loatls). These requirements will always be 
directly determined by the design itself. However, the over- 
all tolerance budget will usually be driven by the liming 
within lite I PI ' complex. 
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Tolerance Mechanisms in Clock Distribution Networks 



As described in ihe accompanying article, we are attempting to guard against a 
number of statistical toleiancing mechanisms, such as skew and jitter, that reduce 
the precision with which a clock signal can be delivered Here we present an 
overview of these mechanisms.' For the purpose of considering system timing 
issues, it is useful to separate the system state architecture into a timing environ- 
ment and a computation environment (see Fig 1 1 The boundary between these 
two parts of the system is composed of the system state devices Except for seg- 
ment delay times and communications locality, we don't address the details of the 
computation environment here. The timing environment can be further broken down 
into three sections the clock or pfiase generator, the clock distribution network, 
and the memory elements. 

The clock generator supplies the signal whose edges eventually dictate when 
switching occurs throughout the system. The clock generator determines the 
period, pulse width, number of phases, and relative phase separation of the clock 
waveform. The primary attributes of the generator to be specified at design time 
are the waveform period and stability or jitter For systems that use a processor 
chip, the period It usually specified by the manufacturer of the processor Instability 
(jinerl in the waveform emerging from the generator detracts from either perfor- 
mance or reliability Beyond these, there are frequently secondary issues and 
features that contribute to system testability — frequency and duty cycle adjust- 
ability, overtone suppression, modes fburst. single-step, fast, and slow), scan-path 
drive and timing, and others 

The state devices are flip-flops, latches, or memory devices of some type. New 
devices with enhanced testability features are appearing more frequently The 
state devices play an important role in determining the low-level timing con- 
straints in that their setup, hold, and minimum pulse width requirements must be 
satisfied at full clock speed 

The clock distribution network is a network of buffers and interconnects that 
conveys the clock signal to the clock consumers. It is responsible for fanout ampli- 
fication and is generally tree-structured In simpler systems, all of the fanout can 
occur in a single buffer. In larger systems, thuusands of copies of the clock can be 
produced, requiring many levels of buffering (12 to 15 levels in some supercom- 
puters!. From a timing perspective, the ideal situation is for all of the copies of the 
clock waveform to emerge from the leaves of the clock distribution network at the 
same moment However, the devices (both buffers and interconnects) that make 




Fig. I: Stale architecture model Any synchronous digital system can be decomposed Into a 
riming environment and a compute environment. Ihe design Issues specific to the timing 
environment aie becoming critical in PC and workstation designs 
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This measurement shows the cycle-to-cycle 
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fig. 3. Jitter, as it occurs m clock buffers, is generally the result of noise m the power environ- 
ment (return currents, image cunems, etc I modulating the switching threshold of the buffer 

up the paths through the clock distribution network have a statistically distributed 
delay These distributions can be time-invariant (static) or time-variant (dynamic). 
An example at a statically distributed tolerance is skew in clock buffers This is 
the variation in delay either from pin to pin in a single package or from part to 
part. Interconnects can also exhibit tolerancing This is most easily thought of as a 
variation hi the propagation rate of several picoseconds per inch (10 to 40 ps/in). 
Interconnect tolerancing is frequently a source of unanticipated timing failures. 

An example of a dynamically distributed tolerance is jitter The placement in time 
of a waveform edge that has jitter varies from one cycle to another It can be 
thought of as having a period that changes from one cycle to the next Fig. 2 
shows an example of this variation. Jitter can be added to the clock waveform m 
two places, at the generator or in the buffers. At the generator, jitter can occur 
through either internal noise or dynamic temperature or supply voltage instabilities. 
Jitter added in the clock buffers is caused primarily by noise in the power environ- 
ment (return and image currents in power planes sweeping past power and 
ground pins, etc ) causing time-varying shifts in the device's switching threshold 
This is illustrated En Fig 3 Note that jitter Ian expansion of the distribution of the 
edge placement) is incieased when the noise voltage is increased or the edge rate 
of the signal arriving at the buffer is decreased The management of |itter at con- 
sistent and acceptably low levels is perhaps the single greatest challenge for 
designers nf systems that incorporate many of the new high-performance proces- 
sors A more in-depth discussion of ptter measurement and management can be 
found in references 1 and 2 

There are also statistical variations in how two identical parts are used For 
example, one system may run a little warmer than another, another may have a 
little more noise in the power environment, and so on. Some of these tolerances 



are time-variant and some are not As shown in Fig 4. these device-level distribu- 
tions can be statistically cornbinedt to give a system-level distribution on the path 
delays m the clock distribution network. This system- level path delay distribution 
has a mean value that is sometimes called the nominal delay. By statistically 
combining the individual nominal delays along the path, one computes the 
nominal delay for thai path 

When usmg the nominal delays, if is important tp keep in mmd that there is actually 
a delay distribution This means :hat even it every oath m the design is specified 
to be identical, when the product is manufactured there will be product-to-product 
variations m the propagation delay of any given path, there will be path-to-oath 
variations withm any given machine, and there will be cycle-to-cycle variations on 
a given path in a given machine The result is that one must design the system in a 
manner that both suitably minimizes these tolerances and consciously considers the 
fact that the tolerances will alwavs be nonzero. The design is said to be statistically 
stable when it has this charactenstic 

When the tolerances in the system accumulate beyond the value anticipated by 
the designer, the design is said to be statistically unstable. In statistically unstable 
designs, some small fraction of the manufactured systems will experience timing 
failures despite the absence of any physical defects In these systems, the clock 
can arrive at times other than the designer anticipated, and this can mean that 
one or more of the state device timing requirements (setup time, hold time, or 
minimum pulse widthl will be violated 

Violations of any of the device-level timing requirements can result in statistically 
unreliable switching at the state devices This can cause unpredictable deviations 
in normal system-level behavior These faults can be extremely difficult and time- 
consuming to isolate In fact, the failure modes exhibited by systems with internal 
timing problems are easily among the most difficult to diagnose using conventional 
troubleshooting methods. It is frequently necessary to employ an analytic approach 
to find these faults in any sort of efficient manner These failure modes include. 

• Intermittent or nonrepeating 

• Low fiequency of occurrence (minutes through weeks) 

• Migration of the symptom location through the system 

• Hibernation (failures occur as device parameters change slightly with age) 

• Statistical 
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In general, the difficulty of any particular timing environ- 
ment design can be estimated from two facets of the design: 
the number of clock loads and t he amount of allowable 
clock tolerance, expressed as a fraction of the period. One 
threshold of difficulty occurs at about ten board-level clock 
loadst and tolerance budgets that are less than 10% or so of 
the period. For the typical 06-MHz system we have assumed 
that the loading (15 to 20 clock loads) ranks it as somewhat 
difficult. The tolerances within the CPU complex of 200 and 
700 ps represent 1.3% and 4.7%. respectively, of the 15-ns 
cycle time. This represents a very challenging timing re- 
quirement. Table II summarizes Pentium clock tolerancing 
for various system configurations. 

Table II 

Clock Tolerancing and Loading 
within the Pentium CPU Complex 



Clock 
Speed 
(MHz) 



Cache 
Size 
(bytes) 



60 or 66 None 
66 256K 



60 
60 



512K 
256K 



Tolerance 
(ps) 

N/A 
700 

800 

800 



Number of Loads 



1 (CPU only ) 

12 (CPU, cache 
control, 10 SRAM) 

20 (CPU, cache 

control, 18 SRAM) 

12 (CPU, cache 
control, 10 SRAM) 



Design Example 

In this section, we attempt to impart some insight as to where 
the tolerance budget comes from. We illustrate some of the 
aspects of the design that are major drivers of this budget. 
Our goal is to show the importance of having complete and 
accurate design information at every step of the process. 
However, the process of completely and precisely evaluating 
each component of that budget is complicated, and is beyond 
the scope of this article. The interested reader is directed to 
References 8 and 9 for a more in-depth discussion of the 
design decisions presented here. 

Before describing the design, we encourage the reader to 
adopt the slew that every design decision that pertains to 
clock paths should be made very carefully and considered 
from the perspective of how that decision impacts the toler- 
ancing of the clock. It is a fact that every physical design 
decision (huffer selection, transmission line geometry and 
impedance, termination, grounding schemes, etc.) that 
relates to the clock paths impacts clock tolerancing. 

Preliminary Decisions. Our example design here is a fully 
synchronous 06-MHz system with a 2o6K-byte second-level 
cache. It is based on the use of the Intel 82496 cache con- 
troller and the S2491 cache SRAMs. In this discussion, we 

1 Most clock butlers have 10 or fewer outputs. Wnen the number ot loads in a design exceeds 
this level, either multiple loads must be clustered on each output or a multichip solution is 
required The lormer increases the load capacitance range iC- :3 , - C mn ) any output can see. 
which increases the difference in arrival time between the fastest and slowest conditions. 
The latter solution, using additional devices, increases cost and the length of the clock paths, 
which in turn increases the opportunity for tolerancing to occur in the clock 




Clock 
Driver 



Circles Show Locations ol Clock Pins 

Fig. 3. Intel suggests this placement for use with their second-level 
cache chipset. 

make almost no assumptionstt about circuitry beyond the 
CPU complex, since the design challenge lies with the 
clocks within the complex. Beyond this, we assume the Intel 
suggested device placement (Fig. 3). Placement must be 
very carefully considered for these devices not only from a 
clock-distribution perspective, but also from the perspective 
of the times of flight of all of the data, address, and control 
signals. These times are very precisely specified in the 
Pentium specification. 

As stated earlier, the typical design is expected to have a 
total of 15 to 20 board-level clock loads. To minimize clock 
tolerancing caused by variations in the load capacitance, it 
is desirable to drive the system in a point-to-point fashion. 
This means one clock load per clock buffer pin. We have 
selected a 20-output static clock buffer for this role. It has a 
pin-to-pin tolerance (skew) of 500 ps. 

The interconnect for the design being described here was 
also very carefully considered. It was decided to route all 
clocks in microstrip (typically less tolerancing than stripline 
because of a faster propagation rate ). An interactive field 
solver was used to design the microstrip. The resulting 
propagation rate is 146.4 ps/in. 

Predicting Actual Clock Tolerances. A good way to begin is to 
do an inventory of where the clock loads in the system are 
expected to be placed and get as much information as pos- 
sible about what types of loading they will present. Intel 
provides very complete pi-modelsttt for all of the pins on 
the devices within the Pentium CPl* complex (also known 
as the "optimized interface group"). These models provide 
minimum, maximum, and typical values. The minimum and 

tt We will make relerence to worst-case external clock loading when we do the load/ 
placement inventory 

ttt A p.-model is a standard ac model of an input pin. consisting ot a parallel inductor, a series 
capacitor, and another parallel inductor 
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Fig. 4. Most of the clock nets in our design can be viewed as simple 
series-terminated transmission lines driving single capacitive loads. 

maximum ratings permit an accurate determination of the 
range of distortion delayt that will oc cur at any pin type. 
Usually, the best a designer can hope for in terms of pub- 
lished parametric pin data is typical input capacitance values. 
This only permits estimation of the typical distortion delay, 
not the range. 

When the clock load inventory is completed, the designer 
will know approximately how far most loads are from the 
clock buffer and which buffers are most heavily loaded (typ- 
ical). This information lets the designer estimate how late 
tlte slowest load typically reaches threshold. From this value, 
the other clock paths can be adjusted (e.g., by serpentining) 
to align their typical delays with the slowest one in the sys- 
tem. For this design, the result of the inventory is that the 
largest mean path delay is 1586 ps. The delay ranges for all 
of the other paths in the system are centered on this value. 

Since we used point-to-poinl distribution formosttt of the 
clock paths, the general structure of the clock nets is shown 
in Fig. -1. The general formula for computing the lolerancing 
at I his point is: 

tolerance m , ( = skew,,,, + skew PS , + jitter, 

Skew,,,, is the intrinsic skew, that is, the delay variation of 
the buffer (pin-lo-pin in this case). For our buffer, this is 500 
ps. Skew,, xl is the exlrinsic skew, that is. the delay variation 
along the net. Jitter is the peak value, rather than rms or 
some other statistical jitter metric. 

Extrinsic skew is not a single mechanism. It can be broken 
down into two major components: 

skew exI s ALTprt + tol mfg , 

where ALT p ,| is the variat ion in t he propagation delay of a 
signal down a loaded transmission line. It takes into account 



t Distortion delay is that component ol the delay thai a clock edge enpenences as it arrives at 
Ute load and enters the die The parametrics of the pin. as represented by the pi-model, act as 
a (liter The more the high-end spectral content ol the edge is attenuated, the more the slope 
ol the edge it reduced, adding delav in the amount ol time it lakes the wavelorm to climb to 
threshold What is important with the clock is not absolute delay, bul delay variation, so when 
the parametric! vary more widely, mora variation Itoletancel can occur in the timing al the pin 
This variation is olteri referred lo simply as load capacitance varalion 

tt Because ol a ?00dc allowable dilference in arrival lime between Ihe processor and the 
cache controller, these iwo loads are actually clustered at the end ol a single clock net This 
is discussed in much more detail in Reference 4 



the range of loads seen at the end of a net. Tol n ^g is the man- 
iifacturing tolerance of the interconnect. It ranges from about 
1 ps/in to about 50 ps/ih times the length of the interconnect. 

ALTpd can be computed from: 



ALTp,, = LT, 



LC„ 



- /! + 



LCij 



where L is the length of the net in inches and Tpd is the 
unloaded propagation rate in ps/in C\max and Clnun are the 
maximum and minimum values of load capacitance. To com- 
pute the difference in arrival times between two clock loads, 
these values will be from different pins. Equivalent values 
for C| can be computed from pi-models. Co is the intrinsic- 
capacitance of the net. 

Following this general format for computing the tolerances, 
we can compute a worst-case difference in arrival limes of 
the clocks to the cache controller and the cache RAMs. 

700 ps > skew inI + ALT,,,] + tol luf g + jitter. 
Plugging in what we computed. 

700 ps > 500 + 90 + 60 + jitter, 
which gives us the constraint on clock jitter 

50 ps > jitter. 

The overall tolerance budget is summarized in Fig. 5. The 
jitter conslrainl is very aggressive for PC and workstation 
class computers. Normally, this constraint is a full order 
of magnitude higher. Keeping noise levels low enough to 
meet this constraini will present some unique measuremeni 
reeiuirements. as we shall see in the next section. 

Incorporating Measurement Information 

We have, thus far, described a number of the more challeng- 
ing issues that must be addressed in producing a (ili-MHz 
Pentium design willi statistically slable liming. We have at- 
tempted to emphasize the importance of employing informed 
design practices, The basic tenet of these practices is that 
important design decisions (e.g., timing verification) are 
based upon deliberately and accurately gathered design infor- 
mation. The better this design data is. the better the design 
decisions that are based upon this data. In the case of timing. 



Interconnect 
Manufacturing 
Tolerance 
60 ps 



BuHer Skew 

500 ps 
IPin-to-Pin 




AC, Effects 
90 ps 



Jitter < 50 ps 



Total Budget = 700 ps 

Fig. 5. After accounting for all of the toleranting mechanisms we 
have Utile or no control over, OUT typical Pentium design can tolerate 

approximately 50 ps of jitter. 
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we are talking about all of the low-level tolerance information 
required to compute an accurate tolerance budget 

As noted on page 70, the only significant component of the 
tolerance budget that can be found in data sheets is the 
buffer tolerance, All of the other low-level tolerance infor- 
mation must be determined through measurement. It cannot 
be generated for a design al one company and shared with 
others, The tolerance Information is determined !>>■ 'he spe- 
cific methods and devices employed in a particular design, 
and each design is unique in these regards. 

Perhaps the most notable measurement information relates 
to the very tight jitter allowance. An upper limit of •">() ps will 
require exploration and experimentat ion of various design 
alternatives (device placement, bypass Ottering, ground 
plane cuts, etc.) to determine their exact effect on jitter. 
Jitter caused by switching noise will be first -order sensitive 
to clock buffer placement. And this may involve some mea- 
surement activities that are very new to PC and workstation 
design activities. 

Measurement is usually \iewed as a stimulus and response 
process. Stimulus gear includes pulse and function genera- 
tors and waveform synthesizers. Response gear includes 
oscilloscopes, time-interval analyzers, spectrum analyzers, 
and so on. Response is unquestionably important when the 
measurement of very low-amplitude jitter (10 to 50 ps) is 
being performed. However, one of the less well-understood 
facets of precision measurement relates to the specification 
of stimulus gear and methods for these measurements. In 
the high-speed PC and workstation designs we're discussing 
here, stimulus issues center primarily in two areas: charac- 
terization activities and applications calling for an alternate, 
adjustable clock source. As we shall see, the precision of the 
waveform submitted to a device under test has a significant 
impact on the quality of the design data that results from the 
measurement. In this section, we discuss a number of mea- 
surement methods that apply to these two areas. 

Instrumentation Issues. For all of the measurements described 
in this section, the way the measurement is made and the 
quality of the instrumentation employed in the measurement 
are issues of genuine importance. The importance of preci- 
sion cannot be underestimated. Any tolerance on the mea- 
surement must also be included in the final tolerance data. 
That, of course, means that measurement tolerance directly 
detracts from system performance. 

The very low levels of jitter allowed in the systems we're 
discussing makes the measurements very challenging. For 
example, the waveform t iming uncertainty or jitter of the 
source (pulse generator) must be much less than the jitter of 
the device under test (DUT). There are two reasons for this. 
The first is to avoid corrupting the measurement. A good 
rule of thumb is to try to keep stimulus jitter an order of 
magnitude below what you are expecting to measure. In that 
way. the majority of the jitter measured is what occurs 
within the DIT. The second reason for low source jitter is 
that the tolerance budget establishes an upper bound on the 
amount of jitter permitted on the clocks distributed to the 
loads, and the total jitter on those clock signals includes 



DUT 




> J1+J2 



J2 

Powei 
Environment 
Noise 

Fig. 6. When the; device under test is a static clock buffer it acts as a 
jitter mixer, combining noise-induced jitter with jitter coming In 
from the signal source. For tight systems like Pentiums, it is clear 
thai both the source jitter and the power environment jitter must be 
kept to a nuninium to permit reliable testing and characterization. 

jitter from the signal source. Consider, for example. Fig. 6, 
which shows a clock buffer being driven by an external sig- 
nal source. The buffer can be viewed as a "jitter mixer." that 
is, the total jitter transmitted to the clock loads is the sum of 
the jitter that the buffer adds because of noise (J2) and the 
jitter on the externally generated waveform that drives the 
buffer (Jl). If Jl is significant with respect to .12, it will 
swamp the measurement. Furthermore, if .11 + .12 exceeds the 
jitter limit, the system will not function properly during the 
measurement. Tlus brings up an interesting point. If you plan 
to make these sorts of measurements and use an external 
signal source, you must account for the jitter of whatever 
signal source you may use in the tolerance budget. 

In our Pentium design, our 50-ps allowance for jitter means 
that if we plan to use a signal source with 15 ps of jitter, we 
should limit jitter in the system to less than 35 ps. A 10-ps 
source w ill permit the design to work with 40 ps of in-system 
jitter. However, to use a source with much more than 15 ps of 
jitter means great er design difficulty in minimizing in-system 
jitter,! and increasing difficulty in interpreting system-level 
jitter measurements because of the difficulty of determining 
how much of the jitter is from the source and how much is 
from the system. 

Substitute Clock Measurements. The most common reason for 
using an external source to drive the clock is to do system- 
level timing margin testing and verification. The fundamental 
question behind these measurements is how sensitive the 
system is to imperfect device timing, hi other words, the 
sensitivity of the system to variations in parameters such ;is 
frequency, duty cycle, skew/jitter, or phase separation Tt is 
being determined 

Fig. 7 illustrates a measurement setup for one type of mar- 
gin testing. Specifically, the setup permits investigating how 
sensitive load number one is to various types of parametric 
loleraneing by controllably varying the parameters of the 
waveforms produced by the signal source. For example, by 
advancing the phase of the waveform to load 1 and noting 
where unreliable switching occurs, and then retreating the 
phase of load 1 and again noting where unreliable switching 

t It is probably a useful rule of thumb thai when the stability requirement ol the clock in a 
mass-produced computer system exceeds the stability lound in precision pulse generators, the 
requirement is perhaps too aggressive 

1 Phase separation is a parameter m systems with multiphase clocks. It is the minimum sepa- 
ration between an edge m one clock phase and an edge in another 
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Fig. 7. The margin available al a specific load in a system i-an be 
examined by driving that load from a two-channel signal source and 
carefully adjusting the relative phase of the channels until unreliable 
snitching is detected. 

occurs, the operating limits of the load 1 cloc k can be esti- 
mated, t It is common during the course of a design to need 
to adjust or ascertain the tolerance at a specific point in the 
system (i.e., a point tolerance). For example, lite clock to a 
particular point in the system may have to be forced to be 
earlier, or less toleranced than originally assumed, because 
some aspect of the segment bounded by that state device 
lias changed. 

Another crit ical verification is that the jitter that actually 
occurs in the final hardware is acceptably low. The designer 
starts with an assumption of what can lie achieved. However, 
accurately predicting jitter is difficult, even with "representa- 
tive" assessment boards and experiments. Front-end assess- 
ment of jitter is important, but only an estimate can be pro- 
duced without final hardware. Only the final hardware will 
have the actual switching activity, the actual return and image 
currents, and the actual paths and obstacles that steer these 
currents. To verify jitter, it's necessary to measure it in a 
variety of locations and switching conditions. 

One other significant application of an alternate, adjustable 
clock source occurs during debugging. The external clock 
can bypass either the clock source or paths through the dock 
distribution net work to permit the investigation of a timing 
problem at the loads. The benefit of this, of course, is that a 
defective source or clock distribution network can be by- 
passed or the loads supplied with a clock with jitter reduced 
to below normal operat ional levels. 

Characterization Measurements. The verification activities 
described in the previous section are intended to determine 
how- sensitive the system is to imperfect timing. Device 
characterization measurements ask the question from the 
other side — how imperfect might the timing be? This class 
Of measurements includes fixtured device measurements. 

For example, phase-locked loop clock buffers are basically 
active signal sources. As such, they have jitter of their own 
( intrinsic jitter). To characterize various facets of this jitter 
( cycle-tO-cycle deviation, phase noise, jitter spectrum, set- 
tling time, susceptibility to power supply noise, etc.) without 
corrupt ion from some external effect, it is important to sup- 
ply the device with a stable reference signal and a clean 
power environment (Fig. 8). Note thai a measurement of the 
intrinsic jitter of a well-fixturcd phase-locked loop clock 
buffer does not establish how the device will perform in the 

I Of course, this only ^hows the SBnsltwity of that particular system However, that rosull can 
then he guarribaniled to take into account what mioh.t happen across a larger population ol 
systems 



Intrinsic Jiner' 
iPeak-lo-Peak. 
RMS Spectrum 



Fig. 8. A stable reference signal should be supplied while character- 
izing a phase-locked loop. 

system. Instead, it establishes an upper bound on stability. 
The live system will have a noisier power environment and 
less stable reference signals. The spectrum of these distur- 
bances will not likely be consistent in every application, nor 
will it be easily predicted- The behavior of the phase-locked 
loop is affected in a very complex way by the superposition 
of these various external processes. 

Another measurement process that involves the clock buffers 
is the determination of so-called "derating factors." The pub- 
lished tolerances for clock buffers include not only process 
and manufacturing variations, but also consideration that 
the pans may be operated across a range of temperatures, 
operating voltages, and loadings. The system designer has 
no control over how buffers vary because of process varia- 
tions, but does have control over the range of temperature, 
voltage, and loading in the design, and may wish to attempt 
to remove that part of the buffer tolerance that is attributable 
to these margins on the operating ranges. A series of fixtured 
device measurements made wiiile carefully varying some 
environmental variable can yield estimations of how much of 
the published tolerance is attributable to the environmental 
operating range. 

There is also a role for board-level measurements. As stated 
earlier, the jitter of a clock buffer (phase-locked loop or 
static) is affected to a large extent by the level of noise in 
the power environment. More specifically, it is determined 
by Uie noise where the device power and ground pins attach 
to the power and ground planes. This noise is caused by 
image and return currents in those planes. There arc places 
on the board where this noise is significantly higher than 
other places. Furthermore, the gradient of these changes 
can be fairly tight, with quiet points existing millimeters 
from points that carry high image currents. All this means 
that buffer placement and orientation on the board have an 
impact on clock jitter. It Ls possible to evaluate approximately 
where the quiet locations are on a "technology board." Fig. !) 
shows such an experiment. The externa] signal source is 
used to drive a representative collection of switcluiig gates. 




High-Speed 
Oscilloscope 



Noise activity 
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lor clock buffer 
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orientation. 



Fig. 9. By examining the power environment noise in the region 
where the dock buffer is expected to be placed, the quietest power 
and ground connect ion points can be determined. 
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It is unlikely that llie gates on the technology board will be 
exactly Ihe circuitry I hat appears in the final design, since 
this sort of activity is mosl likely performed very early in the 
design process. A grid of test points in the region where the 
buffer is likely to be placed offers visibility into Ihe power 
and ground planes, and these can be evaluated by a high- 
speed oscilloscope or spectrum analyzer. Once it is known 
where the quiet locations are. the placement and orientation 
of the buffer can be specified. 

HP 8133A Pulse Generator. 1011 For many of the measurements 
described in this section, it is critical to use a high-precision 
adjustable signal source. The HP 8133A pulse generator 
(Fig. 10) is an excellent choice for the stimulus instrument 
in these measurements. It is stable, accurate, and precise. 
The rms jitter for this instrument is warranted to be less 
than 5 ps. Both authors have had the opportunity to charac- 
terize a number of these instruments. The result of these 
characterizations is that the distribution is approximately 
Gaussian. Furthermore, for pulse repetition rates below 500 
MHz, the rms jitter of the instruments is typically 1.2 to 1.3 
ps. Rms jitter is equal to one standard deviation of the jitter 
distribution. Worst-case jitter can be taken to be six standard 
deviations. For a Gaussian distribution, this means that 
worst-case jitter is approximately 8 ps. Applying this to our 
50-ps Pentium tolerance budget, we would have to ensure 
that the system jitter is less than 42 ps to ensure that the 
system functions correctly during testing. This also means 
that most of the jitter of the measurement comes from the 
system and not from Ihe external source. 

When the HP 8133A is configured as a multichannel inst ru- 
ment (Option 003 is recommended for clock characterization 
and testing activities), the phase delay from one channel to 
the other can be agisted in 1-ps increments from the front 
panel or in 300-fs steps over the HP-IB (IEEE 488, IEC 625). 

If a less stable or precise source is used for these measure- 
ments, the quality of the results could be compromised. For 



Fig. 10. TKe HP8133A3-(iHz 
pulse generator is an excellent 
candidate for use as a high- 
stability, ltigh-resoluuon signal 
source for testing Pentium and 
01 her high-speed processor 
designs. 

example, if we assume jitter levels of just a few tens of pico- 
seconds, the system may not even function properly during 
testing and the measurement of any jitter in the system will 
be less meaningful since the minority of the jitter will come 
from the external source. 

Summary 

In this article, we have reviewed some of the significant 
challenges (hat exist in designing a statistically stable timing 
environment for a 66-MHz Pentium system. Many of the dif- 
ficulties described easily generalize to most of the other new- 
high-speed processors as well. We have advanced the argu- 
ment that a new. more informed approach to designing the 
timing for these more aggressive systems is required. This 
informed design approach requires the determination of 
important design information at the front end of the design 
process so that important subsequent design decisions can 
be made knowledgeably, with more predictable results. 

We also examined a variety of measurements that support 
this approach. Our tolerance budget for a typical Pentium 
system revealed much more sensitivity to jitter than has 
been common for designs at this level. Our discussion cen- 
tered on the measurement of jitter-related design informa- 
tion. In the course of discussing these measurements, we 
also examined the role of stimulus equipment. Specifically, 
we discussed what impact various facets of the performance 
of a high-stability pulse generator would have on Ihe quality 
of the measurement data. For example, the simple decision 
to use a higher-stability pulse generator as an adjustable 
substitute for Ihe clock means that the design can have 
higher levels of intrinsic jitter (i.e.. a simpler design) and 
Continue to function during testing, hi the course of our dis- 
cussion, we showed how the HP 8133A pulse generator can 
be employed in designs as aggressively timed as Pentium 
and others. 
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backup product design, firm- 
ware design for the HP 
9145A tape drive and the HP 
, and mechanism control firm- 
ware design for the HP CI 553A autoloader His work 
has resulted in a patent on remote backup to a cen- 
tral computer and two patents on the DDS-DC tape 
format A native of Leeds in the United Kingdom. 
Mark received a BSc degree in computer science 
from Bristol University in 1984 and is a member of 
the British Computer Society. He is married and has 
one son 

27 State Machines for Design 

Mark J. Simms 

Author's biography appears elsewhere in this section 
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Arun K. Iyengar 

Arun Iyengar has been an 
R&D software engineer at 
the Massachusetts Lan- 
guage Lab of HP's Systems 
Technology Division since 
1992 Since joining HP, he 
has worked on developing 
HP's Distributed Debugging 
Environment (DDE) He is 
currently developing debuggers and performance 
analysis tools for parallel and distributed platforms. 
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Arun received his PhD degree (19921 and his MS 
degree (1988), both in computer science, from the 
Massachusetts Institute of Technology, and his BA 
degree in chemistry from the University of Pennsylva- 
nia in 1985 His graduate research focused on paral- 
lel processing Me helped design and implement the 
run-time system for the Monsoon dataflow multipro- 
cessor while at the Massachusetts Institute of Tech- 
nology. He has also worked for DuPont writing scien- 
tific software He has published a number of papers 
on parallel processing and biological computing. He 
is married and has one son. Arun is an accomplished 
pianist whose specialty is classical music He also 
runs and is an avid reader 

Tracy A. Hoover 

A software engineer with 
the Systems Technology 
Division, Tracy Hoover joined 
HP in 1990. She has been 
working on the HP Distrib- 
uted Debugging Environment 
(ODE) proiect since joining 
HP and is one of the lead 
^ engineers on the team. 

Tracy's work on HP DDE included the OSF/Motif user 
interface, the port to the OSF/1 operating system, and 
C++ debugging support She received a BA degree 
from Wellesley College in 1985, with a double major in 
computer science and English. After graduation, she 
worked for Data General on a FORTRAN compiler proj- 
ect, and then at Masscomp m Westford, Massachu- 
setts, on FORTRAN compiler and debugger projects 
In her spare time, she enjoys playing early music on 
the viola da gamba, reading, cooking, and knitting. 
She recently earned her private pilot's license, and 
she and her husband often go flying together 

John R. Vasta 

John Vasta was a software 
engineer/scientist at HP's 
Systems Technology Division. 
I He is now developing soft- 
I ware configuration tools at 
' Atria Software Inc. A native 
of Palo Alto, California, John 
^5 completed his BSEE degree 
from Northeastern University 
in 1985 and joined HP in 1987 John's responsibilities 
involved investigating debugging and performance 
analysis requirements and tools for parallel and dis- 
tributed programs. Lead engineer and architect on the 
HP DDE project, he helped design and implement sup- 
port for debugging C++ programs. He has worked on a 
debugger project. C++ Developer (a component of Soft- 
Bench), and HP C++ compiler projects at HP's language 
labs in Massachusetts, Colorado, and California Be- 
fore coming to HP, he was a hardware and software 
engineer for LTX Corporation John is married and 
has three children, two of whom are twins His out- 
side interests are focused around family life and out- 
door activities. 






Thaddeus S. Grzesik 

Born in Nashua, New 
Hampshire. Ted Grzesik re- 
ceived a BS in mathematics 
and computer science from 
the University of Massachu- 
setts at Lowell in 1993. He 
is now a software engineer 
in the Systems Technology 
Division He joined HP in 
1990 Ted is a member of the team that implemented 
threads support in HP DDE and is responsible for main- 
tenance and enhancements to the graphical user inter- 
face in HP DDE. Earlier responsibilities at HP included 
porting the Verdix Ada debugger to Domain/OS and 
Apollo DN10000. Before joining HP, Ted was systems 
engineer for editors and debuggers at Wang Labora- 
tories, an applications engineer for internal support 
tools at Lincoln Laboratory, and an applications engi- 
neer for printed circuit design software ai Multiwire. 
Ted is married and has one son His hobbies are skiing, 
motorcycling, and alternative music. 

Valerie J. Ho-Gibson 

A project manager with the 
Systems Technology Division, 
Valerie Ho-Gibson joined HP 
in 1 989 as part of the Apollo 
Computer acquisition. At HP, 
she has managed the HP 
DDE project, and has also 
been responsible for other 
program analysis tools At 
Apollo Computer, she was the project engineer for 
language tools. Before joining Apollo, she was a soft- 
ware engineer in the UNIX' 5 system laboratory at 
AT&T Bell Laboratories. Valerie earned an AB degree 
in applied mathematics from Harvard University in 
1 983 and an MS degree in computer science from 
New York University in 1985. Valerie is married and 
has a son. Outside HP, she enjoys choral singing and 
travel. 
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Daniel T L Lee 

With HP Laboratories since 
1981, Dan Lee is manager of 
the image technology de- 
partment. He has been proj- 
ect manager of the data 
compression project and the 
image coding project and is 
the developer of an interna- 
tional color fax standard 
From 1 987 to 1 993, he worked on assignment in 
Japan, serving as research supervisor at Advanced 
Telecommunications Research for four years and as 
project manager at HP Laboratories Japan in charge 
of the digital signal processing project for two years 
Before joining HP, he worked at the IBM Research 
Division in image processing, coding, and speech 
recognition. He has written over 40 technical papers 
for journals and conferences, and his work has re- 
sulted in three patents in the areas of speech and 
signal processing He was born in Hong Kong, re- 
ceived his BS degree in electrical engineering from 
Cornell University in 1973, and received MS and PhD 
degrees in electrical engineering from Stanford 




University in 1975 and 1979 Dan is married, has two 
daughters, and enjoys skiing. 

Akio Yamamoto 

Akio Yamamoto is a member 
^^^k of the technical staff of HP 
^H^A Laboratories Japan, respon- 
^^-_^Sp sible for digital video coding 

' J\ and image communication 

He |oined the company in 
1991, working on multidi- 
mensional signal processing. 
For the project described in 
this issue, he developed a set of wavelet analysis 
tools and demonstrated the effectiveness of the 
wavelet technology in signal processing Akio holds 
BE (19861, ME (1988), and PhD (1991 1 degrees in elec- 
tronic engineering from the University of Tokyo He is 
a member of the IEEE, the ACM, and the lEICE-Japan. 
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Joy Xiao Han 

^^^^^ An engineer in the 
^^^Hj^k Chelmsford Systems Lab, 
I^^^^A J°V Han joined HP in 1992 
^fl£ ..ti^V She is involved with library 
and layout issues for chips 
used in HP 9000 Series 800 
computers. She was a test 
I engineer for the test vector 
I development process de- 
scribed in this issue. Joy was born in Shanghai, 
China and received a BS in electrical engineering from 
Cornell University in 1992 Her professional society 
memberships include the IEEE and the Society of 
Women Engineers. Her two main hobbies are investing 
in engineering companies and playing golf, 
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Jonathan C. Shih 

_ . ^ Born in Chang-Hwa, Taiwan, 

— - . Jonathan Shih is a software 
I A development engineer at 

"r-'yH HP's Computer Systems 
^^B^V Operation. His present re- 
' sponsibilities include testing 

' > ■ strategy, process develop- 

vHt ment, and testing technology 

'" r ^^^ v for a knowledge database 

Jonathan joined HP's Santa Clara Division in 1979. 
He has worked as a software design engineer at HP's 
Commercial Systems Division, as a quality engineer at 
HP's North American Distribution Operation, as a hard- 
ware design engineer for a datacom card used in the 
HP 9000 Model 832 computer, and as materials engi- 
neering manager for HP 1000 and HP 3000 computer 
systems. Before coming to HP, he was a process en- 
gineer at Siliconix Corporation and a manufacturing 
supervisor for the Taiwan Branch of Texas Instruments. 
He received a BS degree in engmeenng science from 
National Cheng Kong University in Taiwan in 1971, MS 
(1977) and Engineer degrees 11978) in material science 
and engineering from Stanford University, and an MS 
degree in electrical engineering and computer science 
from Santa Clara University in 1980. He is married 
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and has two daughters His hobbies include stamp 
collecting and lar-chi. which he has taught 
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Lou Frani 15 a program 
manager at HP's North 
American Distribution Orga- 
nization INADOI His current 
responsibilities include pro- 
gram management for the 
reseller sales and inventory 
tracking program. With HP 
since 1989. Lou has been a 
systems administrator, programmer analyst, and proj- 
ect manager, and was a founding member of the 
NADO EDI (electronic data interchange! program. Lou 
was born in Kensington. Maryland, and graduated 
from the University of Idaho with a BA degree in 
information systems in 1988. 
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Mike Williams is owner and 
principal consultant with 
Amherst Systems Associates 
in Amherst. Massachusetts. 
He is a technical consultant 
in the area of timing environ- 
ment design and precision 
time-interval measurement, 
and provides product devel- 



opment assistance for clock distribution components 
He has worked with the HP 8133A pulse generator m 
several applications and on timing issues for several 
HP divisions He has served on the (acuity of the Uni- 
versity of Massachusetts at Amherst, and has written 
articles and papers on timing environment design. 
Mike 15 married and has a daughter His interests 
include photography, horseback tiding, sailing, the 
design and history ot mechanical marine chronome- 
ters, and shooting sports He is a member of the 
Antiquarian Horological Society. 
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Shahid Mujtaba 13 a principal 
ptoieci engineei at HP Labo- 
ratories He is the principal 
architect of the modeling and 
simulation representations, 
ana designer and impfemen- 
tor of the EMS (enterprise 
modeling and simulation) 
engine He is currently look- 
ing for opportunities for the application of the EMS 
system and methodology within HP. Previously, he 
developed a robot control language for a manufactur- 
ing robot control system The language and controller 
were subsequently transferred to Yokogawa-Hewlett- 
Packard and to HPs Computational Products Singapore 
for use in the HP ThmkJet and keyboard assembly 
manufacturing lines. A native of Singapore, he re- 
ceived a BE degree Ifirst Class Honours) in mechani- 
cal engineering from the University of Singapore In 
recognition of being the top engineering graduate, he 
was awarded the Institution of Engineers, Singapore 
Gold Medal He was awarded a Ford Foundation 
Scholarship for graduate studies at Stanford University 
where he earned MSEE. MSIE. and PhD degrees 
Before joining HP he did manipulator research at the 
Stanford Artificial Intelligence Laboratory of Stanford 
University The AL User's Manual, which he coauthored 
while at Stanford, was translated into Japanese and 
published in book form He has coauthored or authored 
seventeen publications and two films in the area of 
robotics, and five publications in ihe area of enterprise 
modeling and simulation Shahid is named as a co- 
invenior in two patents, one on a method of coordi- 
nated control of motion devices and one on a system 
for hybrid position and force control, both while at HP 
He is a member of the ACM. the IEEE, the Sociely for 
Computer Simulation, the AAAI. the SME, and the 
Association of LISP Users. He's married and his out- 
side interests include ballroom dancing, origami, and 
gardening. 
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Enterprise Modeling and Simulation: 
Complex Dynamic Behavior of a 
Simple Model of Manufacturing 

Simulating a structurally simple model of a manufacturing enterprise 
revealed complex dynamic behavior. Enterprise modeling and simulation 
provided estimates of end-of-life inventory and order delivery performance 
based on interactions of forecast quality, quoted product availability, 
material procurement and safety stock policies, vendor lead times, 
product life cycle, and part commonality. An unexpected result was that 
end-of-life inventory can exist even under ideal environmental conditions. 
Prospective applications of these methods include estimating the effects 
of incremental improvements, verifying impacts of process changes, and 
generating enterprise behavior information. 

by M. Shahid Mujtabat 



Can we understand the potential imparts of process changes? 
Can we quantify the expected amount of improvements and 
benefits? Can we anticipate the effects of environmental 
Changes? Can we predict the effects and side-effects of mak- 
ing changes? And can we do all these before taking action 
and making major resource commitments? 

We suggest that the answer is yes to all these questions, and 
the means is enterprise modeling and simulation. 

The purpose of this paper is to show how enterprise model- 
ing and .simulation research activities at IIP Laboratories 
can be applied to predict system behavior and gain insights 
using sound engineering and scientific principles and tech- 
niques before implementing the new solution at the level of 
the business enterprise. 

In this paper, we first discuss modeling and simulation tech- 
nology in broad terms to provide background and context. 
We then describe one model, the Simple Model, in detail, 
and present the insights gained from running simulations on 
that model and analyzing and displaying the results. An un- 
expected insight was that end-of-life inventory existed at the 
end of the product life cycle even though the method for 
computing safety stocks shoidd theoretically have resulted 
in none when customers ordered exactly according to fore- 
cast. Other interesting insights were that high inventory levels 
can occur when actual orders come in too high or too low 
with respect to forecasts. In other words, forecast quality has 
a major impact on some of die metrics under consideration. 
We then describe the current state of enterprise modeling 
and simulation, future research directions, and possible ap- 
plication areas, including process reengineering on page 86. 
In the appendixes we include more detailed explanations 
and sufficient technical details of the model to permit the 
results to be duplicated by other researchers. A glossary of 

t Author can be reached at email address mujtaba@tipl.hp.com 



terms and a summary of the values lor different experiments 
are provided for quick referenc e on pages 85 and 95. The 
evolution of enterprise modeling and simulation activities at 
HP Laboratories and the place of the Simple Model in tin >sc 
activities provides a historical context and is described on 
page 90. 

Modeling and Simulation 

Extensive literature exists on the simulation modeling pro- 
cess, for example Chapter 1 of Law and Kelton, 1 Chapter 1 
Of Ptitskcr,- Chapter (i of McHaney, and Law and McComas. 4 
The general consensus is that the purposes of the simulation 
modeling process are to define a problem clearly and to de- 
velop a model as a tool to Understand and solv e that problem. 

"Modeling and simulation have become endeavors central to 
all disciplines of engineering and science. They are used in 
the analysis of physical systems where they help us gain a 
better understanding of the funct ioning of our physical world. 
They are also important to the design of new engineering 
systems where they enable us to predict the behavior of a 
system before it is actually built. Modeling and simulation 
are the only techniques available that allow us to analyze 
arbitrarily nonlinear systems accurately and under varying 
experimental conditions." 5 

"The facility or process of interest is usually called a system, 
and in order to study it scientifically we often have to make 
a set of assumptions about how it works. These assumptions, 
which usually lake the form of mathematical or logical rela- 
tionships, constitute a model that is used to try to gain some 
understanding of how the corresponding system behaves." 1 

Thus, a model is a conceptual abstraction of an existing or 
proposed real system that captures the characteristics of 
interest of the system. Modeling is the process of building 
the abstraction (model). 
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"If the relationships that compose the model are simple 
enough, it may be possible to use mathematical methods 
fsuch as algebra, calculus, or probability theory) to obtain 
exact information on questions of interest; this is called an 
analytic solution. However, most real-world systems are too 
complex to allow realistic models to be evaluated analytically, 
and these models must be studied by means of simulation."' 

"Simulation is the use of a model to develop conclusions that 
provide Insight on the behavior of any real world elements. 
Computer simulation uses the same concept but requires that 
the model be created through programming on a computer." 3 

In general, modeling and simulation are useful when system 
prototyping is too costly or time-consuming, seriously dis- 
ruptive, or simply impossible. They are useful for exploring 
proposed system changes by providing performance esti- 
mates of a proposed syst em or of an existing system under 
some projected set of operating conditions. A simulation 
model or set of models can provide an experimental testbed 
on which to try out new ideas or concepts, since it is 
cheaper to experiment in the laboratory than on the real 
system. 

Our premise is that these techniques applied to enterprise 
processes could help predict the behavior of the organization 
more quantitatively than repeated assertion or the application 
of mental models. 

Enterprise Modeling and Simulation 

We define enterprise modeling as the process of building 
abstractions or models of three primary functional compo- 
nents of an enterprise: manufacturing, marketing, and R&D 
(research and development ) for the purpose of gaining in- 
sight into the interactions between these functions and the 
interaction of the enterprise with other enterprises. The 
complexity of the enterprise and the large number of people 
who have ownership of different parts makes it difficult for 
a single individual to grasp a detailed understanding of all 
the components. There is a limit to t he level of complexity 
and the means to share and Communicate it with others that 
can be carried in the head of a single individual. 

Many process changes and decisions are based on implicit 
mental models in the heads of decision makers or advocates. 
Mental models' 1 are deeply ingrained assumptions, general- 
izations, or even pictures or images that influence how we 
understand the world and how we take action. Very often, 
we are not consciously aware of our mental models or the 
effects they have on our behavior, 1 ' Generally mental models 
assume that there are a small number of factors in cause and 
effect relationships. The problem with mental models is the 
difficulty of communicating them, checking their consistency, 
and combining the mental models of different people. It is 
very difficult to estimate the effects of interacting factors 
and to combine mental models into a larger-scale composite 
model that incorporates the insights, knowledge, and under- 
Standing <»f many individuals. 

One means of merging different viewpoints is the use of 
Hierarchical Process Modeling, 7 - 8 which provides an ex- 
plirit, graphical representation of the process with which 
individuals can agree or disagree. Experience in applying 
Hierarchical Process Modeling 5 ' to the building of enterprise 
models suggests that the result is a repository for knowledge 



of the processes we are studying. During its creation, team 
members develop a common understanding of the dynamics 
of model behavior through interaction with one another and 
with the model. The result is an explicit model that reconciles 
differing points of view and a reusable model that serves as 
a foundation on which to build future models. 

There is an awareness that a model can be used to embody 
knowledge of a system rather than be used as a tool. 10 For 
example. Funke" states that at the Boeing Company, simu- 
lation has provided "a forum for the collection of process 
operating rules and assumptions in one medium as a basis to 
develop the model" of a process or system. 

Other ongoing works on the application of models to em- 
body knowledge at the enterprise level of manufacturing 
operations include TOVE 12 and CIM-OSA. 1314 Pardasani and 
Chan 1 "' describe the expansion of an infrastructure for creat- 
ing simulation models based on the ISO reference model for 
shop floor production standards to create enterprise models. 

In applying the process of enterprise modeling and simulation 
we need to engage in activities of modeling in the large ( with 
"model as knowledge") where the major issues of interest 
are communication and documentation, team coordination, 
modularity and large model development, and multimodel 
organization, instead of modeling in the small (with "model 
as tool") where the issues of interest are top-down design, 
informal and formal program specifications, simplification 
and elaboration, and validation and verification. 

In modeling the manufacturing enterprise, the primary area of 
focus is the manufacturing function, which includes, in addi- 
tion to the traditional production and shop floor functions, 
the production and material planning, material management, 
and order processing functions. In traditional modeling and 
simulation applied to the manufacturing domain, computer 
simulations have been applied to the production floor or ma- 
chine shop level to study machine utilization and production 
and material flows and buffers. These methods together with 
traditional operations research methods have helped reduce 
inventory on the production floor and cut build times to a 
level where these are small compared to the other parts of 
the system. Enterprise modeling and simulation expand the 
scope so that traditional modeling and simulation are com- 
ponents in die enterprise modeling and simulation system. 

Enterprise modeling and simulation indicate the impact of 
proposed improvement efforts at the enterprise level before 
the changes are made. The "simulation" in enterprise model- 
ing and simulation is the process of running the model in a 
computer to understand the behaviors over time under differ- 
ent operating conditions and circumstances. It will help us 
identify leverage points and indicate where we can expect to 
get the most impact for a given investment or change. 

According to Senge." "The real leverage in most manage- 
ment situations lies in understanding dynamic complexity, 
not detail complexity." He suggests that most systems analy- 
ses focus on detail complexity (that is. a large number of 
variables), not dynamic complexity ("situations where cause 
and effect are subtle, and where the effects over time of 
interventions are not obvious"). We suggest that enterprise 
modeling and simulation help in understanding dynamic 
complexity, and in addition provide the framework for 
slowly expanding the detail complexity. 
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Fig. 1. Diagram of the Simple 
Model for Lhe nominal case 
experiment. 



Modeling and simulation at the enterprise level are showing 
increasing levels of act ivity. For example, a recent article in 
Fortune magazine 17 discusses business-oriented economics 
ihat focuses on what economists call "the firm" and the rest 
of us call "the company" as the unit of analysis. (Traditional 
microeconomics, by contrast, is concerned with markets 
and prices. It looks at the economy or at an industry, but 
rarely peeks inside the individual enterprise. ) Fortune cites 
the example of Merck's finance team, which built a com- 
pleted model and subjected it to Monte Carlo simulation 
analysis. 

The Simple Model 

The Simple Model (shown with capital letters because of its 
importance in this paper), was one in a series of models 
developed at HP Laboratories (see page 90). The Simple 
Model was named because of its structural simplicity, but as 
subsequent descriptions will show, it exhibits dynamic be- 
havior that is complex and not intuitively obvious until it is 
explained. Expressed in terms used by Senge, 6 the Simple 
Model is a tool for understanding dynamic complexity using 
a model with very low detail complexity. 

The Simple Model was commissioned to abstract a real man- 
ufacturing facility with greatly simplified assumptions, such 
as a single product with a one-level bill of materials and a 
trapezoidal order demand pattern. The purpose of the model 
was to explore the relationship between different factors 
and metrics used in manufacturing. Although the model can 
generate data on many different metrics, this paper will focus 
on two main metrics: (1 ) inventory levels and write-off at the 
end of the product life cycle and (2) customer satisfaction 
metrics. We will first describe the structure and assumptions 
of the Simple Model and then show the results of running 
the model under different conditions. 



Conceptual Description 

Fig. 1 shows conceptually lhe Simple Model of a factory 
producing a product called Adder. t Marketing specifies a 
trapezoidal order forecast profile for customer orders, and 
the number of consignment units (defined as demonstration 
units used in the sales offices). R&D specifies the Adder 
product structure. Order processing quotes a product avail- 
ability of four weeks. Production determines thai lhe build 
time is two weeks, and shipping states that transit time for 
sending the product to the customer is one week. We as- 
sume that the production and shipping processes are under 
sufficient control that they do not vary from these constant 
numbers. 

The problem assumes that the values of class A. B, and C 
parts in the Adder product make up 50, 30, and 20 percent, 
respectively, of the product material cost. In valuing the fin- 
ished product, labor cost is small enough to be factored into 
lhe material cost, and lhe value of the product is the sum of 
values of its parts. In addition, we assume thai the values of 
6-week, 10-week, and 14-week lead time parts make up 25, 
40, and 35 percent, respectively, of the product cost, that the 
vendors deliver the parts exactly on time, and (hat I here are 
no rejects because of defective parts. 

These characteristics are reflected in Table I, which shows 
the value of each part category. There are a large number of 
unit costs and part quantity combinations that satisfy the 
above constraints. The actual bill of materials used for the 
model is shown in Table II. 

The length of the longest lead time among the parts is 14 
weeks for parts A.3, B.3, and C.3. Allowing a build time of 

There was a little bit of whimsy in naming the product The author selected the name from a 
fairy tale in which somebody ordered the biggest adder available, expecting it to be an adding 
machine When the box was opened, out popped a snake Snakes, of course, was an internal 
HP code name foi a class ol workstations. 
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Table I 

Simple Model Adder Product Structure 
(al Product Structure by Part Value 



Part 


Value 


Part 


Value 


Part 


Value 


A.1 


$1250 


B 1 


$750 


C.l 


S500 


A.2 


$2000 


B.2 


$1200 


C.2 


$800 


A.3 


$1750 


B.3 


$1050 


C.3 


$700 



(b) Part Value by Part Class Safety Stock 



Class 


Parts in Class 


Value 


% Value 


Safety Slock 


A 


A.1.A.2.A.3 


$5000 


50% 


4 weeks 


B 


B.1.B.2,B.3 


$3000 


30% 


8 weeks 


C 


C.1,C.2,C3 


$2000 


20% 


11) weeks 




Total 


$10,000 


10(1"" 





(c) Part Value by Lead Time 



Lead Time 

G weeks 
10 weeks 
14 weeks 



Parts 

A.l.B.l.C.l 
A.2.B.2.C.2 
A.3,B.3,C3 
Total 



Value 

$2500 
.$4000 
$3500 
$10,000 



% Value 

25% 
40% 
35% 
loir. 





Table II 
Adder Bill of Materials 




Part 


Quantity 


Unit Cost 


Value in Product 


A.1 


1 


$1250 


$1250 


A.2 


1 


$2000 


$2000 


A.3 


1 


$1750 


$1750 


B.l 


1 


$750 


$750 


B.2 


1 


$1200 


$1200 


B.3 


1 


$1050 


$1050 


C.l 


1 


$500 


$500 


C.2 


1 


$800 


$800 


C.3 


1 


$700 


$700 



I wo weeks and transit time of one week means that the pe- 
riod from the time parts A.3, B.3, and C.3 are ordered in Ihe 
manufacturing enterprise to the time that the product using 
those parts is received by the customer is 17 weeks. This 
means that the policy of waiting for customer orders before 
we order pails from our vendors will lead to an order-to- 
delivery time of at best 17 weeks. 

To quote availability of four weeks requires us to order mate- 
rial and plan production before we receive customer orders. 
The best information we have on current and past customer 
behavior is actual orders, and the best information we have 
on future customer orders is the order forecast. 

Given that we want quoted availability lo be less than (he 
sum of materia] delivery, production, and product delivery 
times, we need to plan ahead of time how much to build 
based on order forecasts. This decision on how much to 
build in future weeks is the responsibility of production 



planning, which each week computes the number of units to 
be started in future weeks. 

Forecasts of future customer orders are estimates; customers 
may order more or less than forecasted. In the event that 
customers order less, we should have no problem meeting 
the demand if we build to meet the forecast. However, if 
customers order more, we might run out of product. To 
allow for this contingency production planning must specify' 
that we need to build a few more units and carry them in a 
stock of finished goods inventory (FGI). The amount of ex- 
tra product to be carried is the safety stock, and depends on 
many factors including the average expected order level, the 
expected fluctuations in orders, and how much we want to 
allow for contingencies. A high safety stock level will pro- 
tect us from low forecasts, but requires a greater investment 
in inventory. One way of specifying inventory levels is to use 
a measure related to number of weeks of forecasted de- 
mand, hi the case of this model, we assume lhal production 
planning specifies two weeks of 13-week leading average 
forecast as target FGI safety stock. 

The discussions for F'GI safety stock are also applicable for 
raw material. There must be enough raw material on hand 
when the time comes to build the product. To allow for ex- 
cess demand from Ihe production line because of high cus- 
tomer demand, and for late deliveries by vendors, we need 
to order some extra material. This extra amount is deter- 
mined by material planning and is the target raw parts in- 
ventory' (RPI) safety stock. The amount of RPI safety stock 
can be determined in different ways. One way is to use part 
classification. 

In practice, part classification indicates Ihe relative impor- 
tance of a part and hence Ihe attention it receives. Since class 
A parts are reviewed more frequently, a smaller quantity is 
carried than for the B or G parts. In our model, part class 
determines the amount of material safety stock to be carried 
in weeks, and all parls are reviewed weekly by malerial 
planning. For A. Ii. and (' parls (he target RPI safely slock is 
4, 8, and 1(5 weeks, respectively, of the 13-week leading aver- 
age forecast. The 13-week leading average forecast and Ihe 
FGI and RPI largel safety stocks are discussed in greater 
detail Under "Target Safety Slock," below. 

Fig. 2 shows Ihe trapezoidal product order forecast supplied 
by marketing. The demand during each week of a four-week 
month is constant , The demand builds up over three months. 
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Fi«. 2. Adder order forecast and consignment demands in units. 
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remains constant for L months, and then reduces to zero over 
three months, so the total product life is L+6 months. In the 
first month, some units are required for consignment pur- 
poses. The mature monthly demand V is 80 units, and the 
total amount of inventory for consignment is set at 1.5 weeks 
of projected mature demand, or 30 units. In our experiments 
we used a baseline value of 6 months for L. This order fore- 
cast results in a lifetime total of 780 units, or a total fore- 
casted production cost flow-through (PCFI* see Glossary, 
page 85) of $7.8 million, exclusive of the 30 consignment 
units. 

Of the many performance metrics for the system during the 
product life cycle, the tltree main ones of interest are the end- 
of-life inventory, which needs to be disposed of or written off, 
the slupment and delivery performance, and the inventory 
during the product life cycle. 

Detailed Description 

The fundamental description of the Simple Model of the 
enterprise and the primary flows and dynamic components 
that interact with it over time are shown in Fig. 3. 

Entities External to the Enterprise. Customers send orders to 
the manufacturing enterprise. In the simulation each order 
for a single unit is sent individually to the manufacturing 
enterprise. The orders go into the backlog of the manufac- 
turing enterprise, and at some point a shipment fulfilling 
each order is delivered to the customer. Customers have the 
expectation that the time between ordering and receipt of 
delivery is the quoted availability, but are willing to wait 
indefinitely for orders. 

The manufacturing enterprise sends orders for each part to 
the respective vendor, shown collectively in Fig. 3 as vendors. 
The shipment of physical parts arrives at some time in the 
future determined by the lead time for the part. Ideally the 
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Fig. 3. Material, order, and information flows of the Simple Model 
simulation. The heavy solid lines represent the flow of physical mate- 
rial, the long-dash linos represent the flow of information related to 
individual orders, and the short -dash line represents the flow of peri- 
odic order forecasts. The containers represent the accumulation of 
physical material or orders. the pointers represent levels uf the quan- 
tities in the containers, and the light solid lines from the containers 
represent this status information being transmitted to the planning 
function. The light solid line from the planning function represents a 
control signal flow that regulates the amount of material flowing 
from RPi to WIP and ultimately to FGI. 



time between the issuance of an order and receipt of lite 
material (parts) should be the lead time quoted by the vendor, 
and for all the rims in this paper, this will be the case. 

Functions Internal to the Enterprise but External to Manufacturing. 

Periodically, marketing provides forecasts of customer 
orders in future periods. Each forecast is a list of the quantity 
of products that are estimated to be ordered in subsequent 
periods. In practice, forecasts are updated periodically and 
estimates for the same month in the future can vary from 
month to month. In the model, the forecast is used to com- 
pute the shipment plan, and to compute the 13-week leading 
average forecast for computing FGI and RPI safety stocks. 
R&D (not shown in Fig. 3) provides a bill of materials 
(BOM) that defines the product structure. Since the BOM 
does not change during the simulation, we do not show the 
R&D function. 

Processes Internal to the Manufacturing Function. This section 
should be read in conjunction with Figs. 1, 2, and 3. 

Order processing accepts orders and keeps track of all out- 
standing orders received from customers, and keeps a run- 
ning total of the quantity of products required in the backlog. 
In addition, it prioritizes the orders by the ranking criterion, 
which in this model happens to be first-in, first-out (FIFO), 
into a ship list. The backlog level is provided to the produc- 
tion planning function. The prioritized list of orders and the 
quantity that needs to be shipped in the current period are 
provided to shipping. 

Shipping fills and ships the orders on the ship list that order 
processing provides. From the point of view of the manufac- 
turing enterprise, the duration between receipt of customer 
order and delivery of the shipment at the customer site 
should be the time period specified as the quoted availabil- 
ity. Filling an order is attempted no earlier than necessary to 
satisfy the quoted availability taking transit time into ac- 
count. An order is filled and shipped only if at the time of 
the attempt the number of units in FGI is greater than zero. 
In other words, shippings objective is to fill outstanding 
orders that need to be filled and not to try to maintain FGI at 
some level. This means that the actual order-to-dclivery time 
for a particular order will depend on whether units are avail- 
able to fill the order at the time the order is due to be 
shipped. If units are not available, the order will have a 
higher priority for being filled in the next period because of 
the FIFO rule used to establish the ship list. 

Production planning computes the current shipment plan 
and build plan. It computes the current shipment plan from 
the current order forecasts and current order backlog to 
attempt to satisfy the quoted availability. It then computes 
the current build plan from the shipment plan, build time, 
current FGI. current WIP, and FGI safety stock. 

To come up with a suitable build plan, production planning 
must know about the characteristics of the system it is trying 
to control, that is, it DtUSt have a model of the system that it 
uses for doing its computation. An important aspect of the 
computation is to take into account the number of units 
already in process rather than relying only on the number of 
units of product required. Such a model is generally a mathe- 
matical or analytical model, and the formulation is described 
in Appendix E The build plan for the current period is used 
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Glossary of Terms and Abbreviations 



Abbreviations 

A/F. Actuai-to- forecast ratio. This is the ratio of the actual orders received to the 
forecasted orders Normally expressed as a percentage A/F greater than 100% 
implies that actual orders came m higher than forecasts, that >s. forecasts were 
low or demand was high A/F less than 1 00% implies that actual orders came m 
lower than forecasts, that is. forecasts were high or demand was low 

BOM. Bill of materials. A description of the components that go into an assembly 
and their respective quantities. 

• Single-level BOM The components are raw materials fabricated or manufactured 
elsewhere (i.e., purchased partsl 

• Multiple-level BOM The components are other assemblies and purchased parts 

EOL End of life lend of product life cycle) 
FGI. Finished goods inventory. 

RPI. Raw parts inventory Raw matenal in stores waiting to be processed 

WIP. Work in process. Raw matenal on the production line being assembled into 
the final product 

PCFT. Production cost flowthrough Dollar value of production passing through the 
manufacturing enterprise. Because of the assumptions underlying the Simple 
Model, in this paper PCFT is synonymous with shipments from the manufacturing 
enterprise. 

Terms 

Backlog. Products ordered by customers but not yet shipped. 

Build Time. The time required for completion of the product when all the parts 
are available. 

Committed Inventory. The total inventory to which the manufacturing enterprise 
is currently committed. It is the sum of the on-order material and the on-hand 
inventory, 

Consignment Inventory. Inventory in the sales offices and for demonstration 
purposes. 

End-of-Life Inventory, The amount of inventory left over at the end of the product 
life cycle, that is, when no more orders are back logged or outstanding for the 
product. EOL inventory includes leftover unused RPI, unshipped units in FGI, and 
consignment inventory. In general, material and products left over at the end of 
the product life cycle are not useful for anything else and must be written off. 

Forecast Quality. Qualitative description of the amount of deviation of actual 
customer orders from forecasted orders. The ratio A/F described above is one way 



to quantify forecast quality Forecast quality is best for A/F = 100% and gets 
worse as A/F moves away from 100% 

Lead Time. The time between placement of an order to the vendors and receipt 
of die material 

On-Hand Inventory. All physical inventory that is owned by the enterprise It is 
the sum of RPI. WIP. and FGI 

On-Order Inventory. Same as on-ardei material 

On-Order Material. The total amount of material tor which orders are currently 
open and which will eventually be received from vendors. It increases each time a 
new order is issued and sent to the vendor, and decreases each time a shipment 
of parts is received from the vendor 

On-Time Delivery. Measures whether the order is delivered to the customer 
within the quoted availability When described in units or dollars, it represents the 
units or dollar value of the deliveries that are delivered within the quoted delivery 
time When described as a percentage it represents the percentage of on-time 
deliveries with respect to the total deliveries. 

On-Time Shipments. Products that were shipped to customers within the quoted 
availability minus the transit time, that is, those shipped to arrive in time to satisfy 
the quoted availability. 

Order Backlog. The total amount of outstanding orders from customers that 
have not yet been shipped. It increases each time a new order is received from 
customers, and decreases each time an order is shipped to customers. 

Order-to-Delivery Time. The time period from order issue to order delivery at 
the customer site. 

Order-to-Ship Time. Time period from order receipt to order shipment at the 
manufacturing enterprise. 

Orders Delivered. Orders that have been delivered to customers. 

Orders Shipped. Orders that have been shipped to customers. 

Product Life Cycle. The general shape of the increase, leveling off, and decrease 
in order volume for the product. We assume here it is trapezoidal. 

S and S-Plus. S is a language and interactive programming environment for data 
analysis and graphics developed at AT&T Bell Laboratories. S-Plus is a product 
version of S that is sold and supported by Statistical Sciences, Inc. 



to I rigger the start of the appropriate number of units in the 
current period. 

Material planning uses the BOM to generate a material con- 
sumption plan for each part that can support the build plan. 
It then uses the material consumption plan, on-order material, 
RPI. RPI safety stock, and part lead times to determine the 
material ordering plan, that is. how much of each part to 
order in the current and future weeks. Details of the compu- 
tation of the consumption and ordering plans are given in 
Appendix L 

Material ordering sends orders for the appropriate amount 
of each pan in the current week to the vendors. As each 
order is sent, the on-order material for that pari increases. 

Raw material stores (not shown in the figures) receives and 
stoics incoming material in RPI and provides material In 
production when requested. As it receives deliveries from 



vendors, it sends information about the shipment lo on-order 
material which is reduced by the amount of the shipment 
received. 

Production receives a build plan and requests as much 
material as required from raw material stores to build the 
number of units required. Only complete sets of parts are 
drawn from stores, that is, if one or more parts are not avail- 
able in sufficient quantities, all parts are drawn partially. For 
example, if the build plan calls for 10 units to be built, and 
there are only 5 units of pari A.3 and more than 10 units 
each of the other parts in RPI, only 5 units of of each part 
will be drawn and sent to WIP. and only 5 units can be 
started, The objective of raw material stores is to fill re- 
quests for material if possible, and not to maintain RPI at 
any particular level. The mathematical derivation of the 
number of units actually started subject In the available 
material is given in Appendix I. 
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Enterprise Modeling and Simulation Applications in Reengineering 



Process reengineering as defined by Hammer and Champy in their book, Reengineer- 
ing the Corporation? is "the fundamental rethinking and radical redesign of business 
processes to achieve dramatic improvements in critical, contemporary measures of 
performance, such as cost, quality, service, and speed " It is being applied at an 
increasing rate by three kinds of companies: those in deep trouble, those not yet in 
trouble but whose management has the foresight to see trouble coming, and those 
in peak condition with no discernible difficulties whose management is ambitious 
and aggressive These three categories cover a large number of companies The 
impact is on processes with throughputs measured in the billions of dollars. 

Reengineering is pervasive, controversial, and disruptive, and has different 
interpretations CSC Index, whose chairman is Champy, 1 states that even though 
they pioneered the practice of reengineering, they are startled by how widespread 
the phenomenon has become Their survey results 2 based on 497 large companies 
in the U.S.A. and another 124 in Europe show that 69% of the U.S. companies and 
75% of European companies are already reengineering (average completed or 
active initiatives in excess of 3). More than half of the rest were planning to 
launch an initiative over the next 12 months or were discussing one 

Hammer and Champy 3 mention three kinds of techniques that reengineering teams 
can use to help them get ideas flowing, boldly apply one or more principles of re- 
engineering, search out and destroy assumptions, and go looking for opportunities 
for the creative application of technology 

A sampling of the literature reveals thai redesign is influenced by the past 
experience of the reengineering team and the recommendations of reengineering 
consultants. Ultimately, many redesign decisions are made on speculation based 
on implicit mental models, convincing arguments by vocal proponents for change, 
sheer optimism, blind faith, or desperation 

A major concern is the uncertainty of predicting outcomes. Radical redesign and new 
ideas bring the possibility of boundless gain or tremendous loss While assumptions 
are being searched out and destroyed ruthlessly, it should not be forgotten that 
some assumptions are rooted in scientific principles which cannot be ignored with 
impunity no matter how highly enthusiastic or motivated the reengineering team. 

Enterprise Modeling and Simulation 

Some areas suggested by Hammer and Champy 11 for reengineering the corporation 
include product development from concept to prototype, sales from prospect to 
order, order fulfillment from order to payment, and service from inquiry to resolution. 

The Simple Model described in the accompanying article is a start towards address- 
ing order fulfillment Modeling and simulating the other processes on the list require 
different kinds of knowledge acquisition. For example, product development requires 



more knowledge about the RSD function, sales requires more knowledge about the 
marketing funciion. and service has not been considered in the current model, where 
the focus is on manufacturing. 

The following paragraphs describe areas where enterprise modeling and simula- 
tion and the enterprise modeling and simulation system may provide value in the 
reengineering effort 

Identifying Processes 

Hammer and Champy 5 suggest that once processes are identified and mapped, 
deciding which ones require reengineering and the order in which they should be 
addressed is not a trivial part of the reengineering effort. Typically there are three 
criteria for making the selection, dysfunction, importance, and feasibility. 

Enterprise modeling and simulation provide one way of gaming insight in these 
areas by generating performance metrics with and without the change under differ- 
ent circumstances. For example, the Simple Model showed the importance of differ- 
ent controllable and uncontrollable factors to the different system performance 
metrics such as EOL inventory and order-to-delivery cycle times. 

After selecting a process for reengineering, an understanding of the current process 
is crucial It is necessary to know what the existing process does, how well (or 
poorly] it performs, and the critical issues governing its performance from a high- 
level view This understanding is the prerequisite to redesign The key is under- 
standing the process rather than completely analyzing it in agonizing detail 

Enterprise modeling and simulation offer at least two ways of obtaining this under- 
standing and possibly showing the cause of the dysfunction First, the very act of 
building a consensus model that different people can agree with sheds light on 
what might not be working Second, simulating the model will confirm or reject 
the validity of what is suspected. For example, after building the Simple Model, it 
was possible to test it in a large number of possible operating conditions to provide 
understanding of the cause and effect relationships. The first rnaior insight from 
simulating the model was that what appeared to be a reasonable way of computing 
safety stock that would go to zero as demand went down actually gave rise to 
end-of-life inventory even though the demand was forecasted accurately. Enter- 
prise modeling and simulation provide a way of gauging the relative impact of 
different process changes as a step towards selecting the appropriate subprocess 
to reengineer, and of quantifying the amount of prospective improvement 

Enterprise modeling and simulation can show the prospective impact of infeasible 
changes. In simulating the proposed reengineering changes, even if they are 
infeasible, the results will indicate if there is any promise in further consideration 
of a particular direction. For example, it is clearly not feasible to have zero build 



The required material is drawn from RPI and goes into WTP 
where it remains for the duration of (he build period. Alter 
that, the completed units go into FGI. 

Target Safety Stock. Inventory is the amount of physical 
material, and ideally the enterprise would like to maintain it 
at or close to zero in RPI and FGI. and only carry it in WIP 
when raw material is being convened into final product. In 
practice, to reduce the effects on production of late vendor 
deliveries and customer orders coming in higher than fore- 
casts, safety stock needs to kept. In die Simple Model, where 
vendor delivery time uncertainty is not an issue, lo allow for 
the contingency that customer orders may come in higher 
than forecast, production planning targets the FGI safety 
stock lo be two weeks of 13-week leading average forecast, 
and material planning targets RPI safety stock for each part 
to be the quantity of that part required for the production of 
the number of weeks specified in Table Kb) of the 13-week 
leading average forecast. 



The 13-week leading av erage forecast at the end of a particu- 
lar week in the future is the sum of the order forecasts over 
the 13 weeks immediately following the particular week 
divided by 13. This average anticipates trends 13 weeks (one 
calendar quarter) into the future, increasing as order fore- 
casts increase, and decreasing as order forecasts decrease. 
In particular, the 13-week average forecast is zero at the end 
of the product life cycle, which means that any target safety 
stock expressed in weeks of 13-week leading average will aim 
for a zero target safety stoc k level at the end of the life cycle. 

Having specified target safety stock in preparation for de- 
mands higher than forecasted, what is the impact if custom- 
ers order exactly according to forecast? The expectation is 
that actual FGI should be equal to targeted FGI safety stock 
level, and actual RPI for each part should be equal to targeted 
RPI safety stock level for that part. 
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time for products and rero transportation times for shipments in the real work), 
but setting those values to zero in the model indicates the theoretical maximum 
benefits of these actions, and the magnitude of the results provides a data po'nt 
for decisions on how much investment to out on driving these two limes to zero 
instead of on other opportunities 

Furthermore, by showing the time behavior of The changes, enterprise modeling ana 
simulation can show when actions can be expected to take effect Inertia is a prop 
erty of most systems, reflected in the time taken to respond to external influences or 
changes Most physical systems are predictable m this respect, but the time be- 
havior for organizational systems such as the enterprise is less predictable simply 
because it is not understood as well Enterprise modeling and simulation help to 
increase the predictability of system behavior given that we know something 
about the system s structure and the behavior of its components While immediate 
improvement for reengmeering is the desired goal, enterprise modeling and simu- 
lation can show the length and causes of delays in obtaining the desired result 

Exposing and Challenging Assumptions 

Hammer and Champy suggest that we question assumptions 6 Enterprise model- 
ing and simulation require assumptions to be stated explicitly during the model 
building process to reconcile differences in points of views Challenges and dis- 
agreements on the validity are with respect to clearly stated assumptions rather 
than differences in opinions resulting from differences in mental models of differ- 
ent individuals. For example, the production planning and material procurement 
processes used in the Simple Model are expressed mathematically In Appendix I 
If these are accepted as rational methods of planning, then there is no question or 
debate on the values of the outputs for a given set of inputs. If processes expressed 
mathematically are not acceptable as rational methods of planning and an alter- 
native method is proposed, then that alternative method can certainly be tried, 
and the results compared with the previous method The debate and challenge for 
improvement becomes one of improving the logic of planning rather than one 
revolving around the meaning of words and labels or one on how the model 
should behave based on past experience or speculation 

The approach advocated by Hammer and Champy suggesis that changes be made 
by understanding the problem and devising the solution This is central to model- 
ing and simulation in addressing problems in the realm of the enterprise. Enter- 
prise modeling and simulation offer a way of testing and verifying that given the 
current knowledge, the results of the simulation do not exhibit any obvious flaws 
before the process is implemented 

Role of Technology 

Hammer and Champy devote a whole chapter to discussing the essential enabling 
role of information technology, and assert that modern state-of-the-art information 
technology is part of any reengmeering effort They caution that the misuse of 



technology can block reengineering altogether by reinforcing old ways of thinkirg 
and old behavior patterns, and that equating technology with automation does not 
result in reengineering 

We suggest mat me application of enterprise modelirq and simulation is a creative 
application of a well-understood technology to the processes of me enterprise 
The technology of modeling and simulation has oeen applied to fields such as 
product design and me design of physical systems, out is only now beginning to 
oe applied creatively m analyzing the processes of the enterprise What enables 
the creative application at modeling and simulation is the tremendous increase m 
computational power In this respect, we would like to suggest another rule along 
the lines of the rules described in reference 1 

Old Rule: Decisions regarding process changes are based on mental models 

and analysis ot historical data 

Disruptive Technology Enterprise modeling and simulation 

Aleiv flute. Decisions regarding process changes are based both on historical 

data and analysis of computer simulated behavior of explicit models with 

explicit assumptions that show me prospective consequences of different 

actions under a large number of operating circumstances 

Conclusion 

Reengineering is a philosophy of renewal and rapid, discontinuous, and drastic 
change in the way corporate enterprises do their woik, which brings with it uncer- 
tainty and fear of the unknown future It is disruptive and controversial, and there 
is as yet no agreement that successes outnumber failures. During the implementa- 
tion. "People focus on the pain of the present and the joy of the past. They forget 
about the pain of the past and the joy of the present " 7 However, given that it is 
occurring on such a wide scale, we suggest that application of enierprise model- 
ing and simulation can increase the chances for success by (1 ) quantifying the 
potential benefits of me reengineered process in an explicit, defensible way, 12) 
illustrating the transition between me pain of the present and the joy of the future, 
and (3) showing the possible outcomes of current actions, thereby making die 
future more predictable and less surprising to those most affected by it 
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Simple Model Simulation 

The Simple Model described above represents a simple pro- 
cess design for a manufacturing facility that is subject to 
simulation. On the surface, the design appears to be reason- 
able and adequate; and in fact is baaed on representative 
data and characteristics of the process. However, simula- 
tions will show some unexpected behavior, as well as the 

envelope of the possible behaviors. 

The Simple Model was executed on an evolving system called 
the EMS system, which consists of two parts: the simulation 
engine part and the data analysis and display part The simu- 
lation engine has continued to develop with each model thai 
we have studied. It captures and abstracts processes in the 
enlcipri.se. The simulation engine is an ohject -oriented, en- 
hanced discrete event simulation software system. 

The initial implementation of I he simulation engine pail of 
the EMS system was the Manufacturing Enterprise Simula- 
tor on the TI Explorer II." The current Implementation runs 



on HI' 9000 Series 700 workstations at the Manufacturing 
Systems Technology Department of HI' Laboratories. The 
implementation language is the Common Lisp Object Sys- 
tem (CLOS). IH The simulation engine has been implemenied 
in CLOS provided by three different vendors: Franz. Inc.,' 1 ' 
Lucid, Inc., 2 " and Harlequin, Ltd. 21 Models subsequent to the 
Simple Model (see page 90) were large enough to stress the 
limits of all three implementations. Graphical oulpul was 
produced using S-PIus. Further details of the history and 
development of the EMS system are given in reference 9. The 
initial version of the Simple Model was implemenied within 
a week based on the full order-to-ship model-- (see page 
90). It then took successive refinement and a tremendous 
amount of time to analyze the results. 

For the reader familiar with discrete event simulation, details 
of the similarities and differences in concept between this 
implementation and conventional discrete event simulation 
are discussed IB reference 9. In general, orders ;uid shipments 
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Fig. 4. Nominal case inventory components as functions of limp. The experimental conditions are shown in Pig, 1. 



arc modeled as the entities of discrete event simulation. 
Backlog, on-order material. RPI. WIP. and FGI are modeled 
as queues. Customers and vendors are modeled <is source- 
sink combinations of orders and material and vice versa. 
Production is modeled as an activity. 

The production and material planning functions, which are 
essentially information processing and decision making func- 
tions, are implemented as mathematical models embedded in 
the simulation. The information generated by these planning 
functions determines when and how many units of product to 
start building ;uid how many units of material to order. Thus, 
we can think of the Simple Model as an analytical mathemat- 
ical model embedded in a discrete event simulation model. 
The analytical model (formulation given in Appendix I) dic- 
tates how the simulation model should behave in die same 
way as the planning functions dictate how operations should 
be handled in reality. The simulation model is the reflection 
of physical reality and reflects the behavior of the physical 
system that is told what to do. 

There are two aspec ts of uncertainty: bias and variance 
Most simulation models focus on variance and assume bias 
(offset ) to be zero. While the EMS system supports the abil- 
ity to simulate the model under stochastic conditions, in the 
runs described in this paper, variance is always zero and the 
emphasis of the analysis is on the situation in which bias 
can be nonzero. 

Each run represents one combination of inputs and parame- 
ters of the system, and the traditional statistical analysis of 
means and confidence levels is nol directly applicable for 
the analysis of these runs. While process variances are im- 
portant considerations in a system, die motivation of this 
work was to identify the first-order effects of the various 
factors, considering the v ariances as second-order effects. 

Details of the timing of the event sequence are shown in 
Appendix II. 



Experimental Results 

Experiment 0: The Nominal Case 

The nominal case experiment assumes ideal conditions for 
testing the model. The purpose is to establish model baseline 
behavior and offer face validation by verifying that results 
are consistent with intuition and the observed behavior of 
the real system. Initial conditions for committed inventory 
and backlog are set to zero. A warmup period of five months 
(2(1 weeks) allows material to be ordered and received be- 
fore customer orders arrive on week 21. The last customer 
orders arrive on week (58. Order forecasts are consistent 
widi the trapezoidal profile already defined, and while they 
are generated weekly, they do not change from week to 
week. Week 21 corresponds to the first week of month 1. 
and week (58 corresponds to the last week of month L+G in 
Fig. 2, Production begins during week 1!) to ensure units in 
FGI at the end of week 21. The computation of FGI and KIM 
safety stock levels is assumed to apply only for weeks after 
week 20. Up to and including week 20. the required safety 
stock level is set to 0. 

Time Response of On-Hand Inventory and On-Order Material. 

Fig. 4 shows inventory levels measured in dollar terms over 
time. The two bottom regions show the on-order material 
and on-hand inventory for consignment units. There is a 
gradual buildup of on-order material, which is rapidly trans- 
formed into on-hand inventory over four weeks, followed by 
a flattening out (since the consignment units are never 
shipped)- The middle region shows on-hand inventory for 
trade or shippable units, which is the sum of RPI. WIP. and 
FGI. The upper region shows the on-order material commit- 
ment for trade units. The top surface of the graph shows 
how total material commitment changes over time. 

Inventory Investment. Committed inventory at the end of week 
20. before the first customer order arrives, is approximately 
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$3.6 million. If orders to vendors cannot be cancelled, this 
$3.5 million commitment must be disposed of if we decide to 
cancel the product before the first customer order arrives. 

During the mature part of the life cycle of the product, the 
on-hand inventory is approximately $2.5 million and the 
total committed inventory is approximately $4.7 million. To 
support shipment levels of $200,001) a week requires $4.7 
million of committed inventory (23.5 weeks of steady-state 
P('FT) and $2.32 million of on4iand inventory (1 1.6 weeks of 
steady-state PCFT), both of which include $300,000 of con- 
signment units (1.5 weeks of steady-slate PCFT). Details of 
the computations verifying these numbers in the simulation 
an' given in Appendix IV-2. The maximum inventory exposure 
over the life cycle is $4.7 million. 

Tin' EOL consignment inventory of $300,000 reflects the 
amount of potential write-off because we did not dispose of 
the consignment units. The EOL nonconsignment inventory 
lor trade units is reflected in the tail of the graph, and its 



value is approximately $04,000. If the material cannot be 
consumed any other way, there is an EOL write-off of 
$6-1,000 of nonconsignment inventory and $300,000 of con- 
signment inventory for a PCFT of $7.8 million under ideal 
conditions of perfect forecast quality and on-time vendor 
delivery. 

Time Response ol Other Metrics. Fig. 5 shows oilier time set ies 
metrics in comparison to orders received. The shipment 
profile (Fig. 5a) is identical to the order profile hut shifted in 
time by three weeks. This is because the four-week availabil- 
ity and one-week transit time require three weeks ol'order- 
to-ship time for on-time delivery. 

Steady-state backlog ( Fig. 5b) is $600,000. or three weeks of 
orders. Again, this is because the four-week availability and 
one-week transit time result in orders slaying in backlog for 
three weeks, that is, the current backlog is the sum of the 
last three weeks of orders. 
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Enterprise Modeling and Simulation Research at HP Laboratories 



Our work a! HP Laboratories on enterprise modeling and simulation is an uulgrowth 
of the factory modeling project, which began in early 1987 While we were work- 
ing in the area of robotic automation for manufacturing, we began to appreciate 
the complexity of the geographically distributed, multientity marketing, manufac- 
turing, and distribution operations necessary tot HP to remain competitive We 
also realized that there were very few tools available to help understand, design, 
and operate these complex systems. 

Having been involved in product design with the evolving use of CAD and CAE 
tools, we thought that there was an opportunity of potentially tremendous magni- 
tude for applying similar technologies to the design and operation of the factory 
and business systems used to market, manufacture, and distribute products. In an 
effort to capitalize on this opportunity, we began identifying the primary elements 
of a single factory and building our preliminary order-to-ship model that spanned 
all maior activity from the receipt of an order to its shipment 

Preliminary Order in Ship Model 

This early model was a vehicle to show the feasibility of applying simulation at a 
scope larger than a production line, where simulation was beginning to be applied 
Developed and proposed for discussion purposes, it was a model to analyze why the 
order-to-ship time for some products stretched to weeks when the application of 
modern manufacturing techniques had reduced the build time to a matter of hours 
More details on the reasons behind this work are given in references 1 and 2 

Full Order to Ship Model 

By late 1988 the preliminary model was ready for testing in a real-world context. 
Data and operational information were provided by a real manufacturing division 
to help enhance our early model This process helped to validate the preliminary 
order-to-ship model and led to the development of the full order-to-ship model 3 
The primary factors considered were order forecast quality, production capacity 
constraints, supplier lead limes, and order filling policies The primary metrics of 
interest were order lateness, backlog, and inventory The model included three 



Fig. 5c shows an initial spike in WIP preceding the start of 
orders by t wo weeks. This happens because the number of 
units started during week 19 is not only what is to be shipped 
two weeks later, bill also the quantity that must be in KG I 
(approximately two weeks of orders) at the end of week 21. 
The WIP levels taper off downwards starting in week 44 
towards the latter pail of the life cycle because as the de- 
sired FGI safety stock level decreases, less production is 
required than is shipped because some units shipped from 
FGI do not have to be replenished. 

Fig. 5d shows material orders. The three large spikes in 
material orders are caused by different lead times for pans 
to fill the targeted KPI safety stock at the beginning of the 
cycle. Each of the three small spikes corresponds to the 
different lead lime pans for the initial WIP spike. Once the 
initial spikes are past, the material ordering volume is ap- 
proximately the same height as the customer orders, except 
that it is shifted earlier in time, showing that once the sys- 
tem has reached mature demand, material inflow in the form 
of material ordered is balanced by the material outflow in 
die form of shipments. Material ordering starts ramping down 
beginning in week 28 just as die orders reach the maximum 
demand for this particular set of circumstances. 

Fig. Be shows RPI as a function of time. Notice that the 
vertical scale is different from the other graphs. The RPI 
level is 7.6 weeks of PCFT during the mature demand period 
and starts ramping down in week 44. Fig. Bf shows FGI as a 



distribution centers, one manufacturing entity, and a centralized sales and order 
entry system It was configured for one-level bills of materials IBOMI, multiline 
orders, and long life cycle products 

Ttie results of the analysis done with the full order-to-ship model were encouraging; 
they showed things that were consistent with real-world experiences le g . high 
forecasts led to high inventory and low backlogl The results also provided a view 
of greater potential by helping to identify areas for future improvement (e g , the 
dominant cause of product shortages is long lead time parts coupled with poor 
forecasts rather than the build time) 

While the results of this model were modest, the building and running of this model 
enabled us to explore some important technologies (i.e.. Hierarchical Process 
Modeling for knowledge acquisition, a discrete event simulation language. SLAM II, 4 
and a knowledge-based environment. Knowledge Craft, for system representation 
and building simulations]. Our efforts led to generalized enterprise-level modeling 
elements and an ob|ect-onented simulator We also identified some new obstacles 
(e.g.. managing large amounts of simulation data, extracting information) to be 
overcome in attaining our goals More details are given in reference 1 

For about a year, no further model development was dune, but rather, much effort 
was put into consolidating what we had learned about the modeling and simulation 
issues. This effort led to the complete overhaul of our modeling and simulation 
code while migrating it to the Common Lisp Object System on HP workstations 
The power and speed of oui system took a quantum leap forward 

Simple Model 

With our improved system ready, we were presented with another real-world 
opportunity to apply our techniques The Simple Model was proposed as a means 
of pulling together the main activities, processes and circumstances involved in a 
manufacturing enterprise. The primary purpose was to understand end-of-llfe 
(EOLI inventory and order delivery performance issues The combined impacts of 
several environmental factors and operational policies were considered in the 



function of time. The FGI safety stock during the mature 
demand week is two weeks of PITT, which is the same 
as two weeks of steady-state orders. The FGI level starts 
ramping down in week 44. 

Inventory Results. The results establish the baseline behavior 
of a system designed to take contingencies into account 
when those contingencies do not occur. Appendix IV pro- 
vides further details for computing some of these results on 
a theoretical or common sense basis. Some interesting ob- 
servations can be made. First, EOL inventory and write-off 
exist even Ihough customers ordered exactly according to 
forecast and we expect safety stock to go to zero. Second, 
the level of inventory required to Support this level of busi- 
ness can be quantified. Third, long lead time parts make up a 
greater percentage of the value of parts on order than their 
percentage in the product Structure. 

EOL inventory is important for short life cycle products 
because die inventory cannot be used for anything else and 
must be written off. In this case it is a result of the way of 
computing safely stock. It occurs if in the early part of the life 
cycle too much material is ordered because of high targeted 
FGI and RPI. For short life cycle products it can be a signifi- 
cant percentage of PCFT. EOL inventory is less of an issue 
for long life cycle products because the leftover invenlory is 
generally a smaller percentage of total PCFT and excess 
inv entory in early periods can be used at a later time. 
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analysis The mode), leveraging our earlier work, dealt with a one-level BOM. one 
factory, one product and subsequently a family of successive products with common 
pans and overlapping life cycles 

Our analysis provided some interesting insights, such as certain matenai procure- 
ment and safety stock policies result m EOL inventory even for perfect o-der fore- 
casts, and with low forecasts, increasing material lead times and olannmg frequency 
result m increased EOL inventory More important, we began to realize that we 
were onto something that could teally have a positive impact for HP In fact, the 
business results led to the development of the planning calenda' model with the 
Simple Model as its foundation We also continued our technical enhancements by 
connecting the output to S-Plus 4 - 8 for data analysis and the creation of a Lotus* 
interface to display output 

Planning Calendar Model 

The purpose ot the planning calendar model 7 6 9 was to determine the effects of 
planning cycle times on inventory levels It required extension of the Simple 
Model to include production planning and material planning cycle times It approx- 
imated a two-level BOM and multiple assembly sites using a one-level BOM at 
one site It used historical forecasts and orders. The primary factors were forecast 
quality, the length of the planning cycle, and the maximum lead times for pans 
The primary metrics of interest were average inventory, delivery performance, and 
inventory levels at the stan of production The primary technical development was 
the application of S-Plus data analysis capabilities to the data 

With this model, material lead times had a dominant effect on inventory levels 
and committed inventory Historically, forecasts were generally low, so for the 
historical data given, the planning cycle time used for the particular product had 
insignificant impact compared to material lead times. There was greater potential 
lor reducing inventory by reducing lead times than by reducing planning time Low 
forecasts increased backlogs. 

Current Modeling Activities 

We are currently finishing an analysis of a single-site manufacturing system where 
we were looking at how to improve the supplier response time The challenges in 



this application include managing a multilevel bill-of-materials and understanding 
the consequences of long, variable test cycle times We are also working with 
sector-level reengtneertng teams to help understate) the consequences of proposed 
changes and explore alternatives 

Our enterprise modeling and simulation capabilities have evolved considerably 
from our preliminary order-to-ship model However, there are still many more 
interesting challenges to address before we reach our goal ol a computer-aided 
Business process design and operation system 

Robert Rittei 
Project Manager 

Enterprise Modeling and Simulation Proiect 
HP Laboratories 
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This nonzero EOL inventory is significant because our 
safety stock policy targets zero safety stock levels in FG1 
and RPJ at the end of the life cycle. Having observed this 
phenomenon in the simulation, we were able to show mathe- 
matically why the EOL inventory is not zero. The formal 
derivation of this result is outside the scope of the current 
paper, but more detailed analysis of the data showed that it 
is the Class (" parts that are left over. The Class C parts will 
be zero in the case when orders come in as forecasted for 
the conditions of experiment 0 only if the target RPI safety 
stock for Class C parts is less than or equal to the l-'i-week 
leading average forecast. Also, for the conditions of experi- 
ment 0. any part with target safety slock greater than 13 
weeks of l-'l-weck leading average forecast will end up with 
EOL material. The behavior of the amount of Class C EOL 
material as the number of weeks of target safety stock goes 
down is given in Appendix IV-3, and an informal explanation 
showing the reasoning behind the EOL material is given in 
Appendix PV-4. 

The nonzero EOL is a function of the number of weeks of 
13-week leading average forecast, i Ither techniques of com- 
puting safely slock, for example using a cumulative leading 
forecast rather than the lU-week leading average forecast; 
might lead to different results. 



before) gives rise to a spike in capacity demand at the begin- 
ning of the product cycle. It could be eliminated by incorpo- 
rating production capacity constraints into production and 
material planning or by allowing FG] In build Up before the 
first order comes in (i.e., before week 21). Both of these 
require production Ed start before week 19. 

Experiment Set la: 

Single t in nil l nil la l>l e Factor Variation 

In the nominal case, the customer order pattern was accu- 
rately forecast. We now consider the situation where the 
actual orders are different from the forecasts. 

We assume that customers order according to a constant 
order forecast profile multiplied by some constant factor 
Actual/Forecast or A/F. A/F is the ratio of actual orders to 
forecast orders; its definition is shown in Fig. fia. In practice, 
marketing would change the forecasts periodically. Since we 
were not modeling the forecasting process, we chose the 
simplifying assumption that although a new forecast is gen- 
erated every week, it is identical to the forecast generated 
the previous week.f Here is an example of bias in the order 
forecast with no variance. The model interpretation is that 
although estimates were wrong in the past, we expect that 
future orders will be equal to the original forecast. This Ls 



Smoothmg WIP and Production. The initial spike in WIP shows , rh(5l5n o. a limitation of the model a use-specilied torecas. con be accepted by Uie model 
how the policy of start ing product ion in week 1 9 ( and not ( am mode i s have ,n t0 ipoiated luslorical loiecasts The reason loi this assumption was to gel 

a better understanding ol the ellect of foiecast bias Fluctuating foiecast deviations make 

interpretation harder 
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Fig. 6. Definition '>f A/F. (a) A/F ratio, (b) Actuals aiul forecasts al 
the current time. 

reflected In Fig. 6b. Actuals came in as shown in the pan of 
the graph to the lefl of the current lime, while the pari to the 
right of the current time line shows the current expectation 
of future orders. 

Clearly, we would expect an effect when A/F is not 100%. If 
A/F is less than 100%, that is, if forecasts are high. FGI will 
start to build up, since production planning has directed a 
larger number of units to be built than are subsequently de- 
manded. Production planning and material planning lake 
this into account and plan to build less and order less mate- 
rial in the future, but the overall material level is higher than 
when A/F is equal to 100%. On the other hand, if A/F is 
greater than 100%, that is. forecasts are low, FGI will start to 
be eaten away because production planning has directed a 
smaller number of units to be built than are subsequently 



demanded. Subsequently, production planning and material 
planning take this into account and raise the production, but 
since they are always estimating low future demand, we 
would expect the inventory level in general to be lower than 
in the case where A/F is 100%. Surprisingly, this intuitive 
result does not hold, as will be seen later. 

We ran the simulations with A/F ranging from 50% to 200% at 
equal intervals of 25%. In addition, we ran it at smaller inter- 
vals in the region of 95% to 125%. 

E0L Write-off. A consequence of keeping forecasts Identical 
for all runs is that the consignment profile does not change 
with respecl to A/F. Fig. 7 shows EOL metrics as A/F ranges 
from 50% to 200%. Note that the changes in value are not 
constant across the horizontal axis. Fig. 7a shows that total 
EOL inventory inc reases as A/F decreases. Fig. 7b shows 
that the percentage impact is even worse, simply because 
the write-off is a higher percentage when I'CFT, which is 
directly influenced by A/F, is lower. For low forecasts, thai 
is, A/F greater than 100%, the EOL inventory decreases. For 
high forecasts, that is, A/F less than 100%, the EOL inventory 
increases. The lower the A/F, the higher the EOL inventory. 

Fig. 7 leads to the obvious conclusion that inventory write-off 
can be reduced by the strategy Of iinderforecasling orders. 
Howev er, this is only one side of the story. The complete 
story is shown in Fig. 8. 

Impacts on Time Series of A/F Changes. Fig. 8 shows the im- 
pact of A/F changes on different time series measures. To 
avoid duller we will not shoir inventory for consignment 
in subsequent lime series. FGI, WIP. RPI, on-order material, 
and on-hand inventory will refer to the material associated 
with trade units unless otherwise specified. 

All of the graphs in each row of Fig. 8 exhibit identical be- 
havior before week 21. This is to be expected, since before 
the first orders come in on week 21. the situation is the 
same for all cases. Only as different amounts of orders come 
in on or after week 21 is the situation different for different 
values of A/F. 

Fig. 8a shows the order forecasts and actual orders for ref- 
erence. The ratio of the values of the two lines at any lime In 
the graph is equal to A/F. 

Fig. 8b shows the backlog and actual Orders time series on the 
same scale. Notice how the backlog increases spectacularly 
as A/F goes beyond 125%. Fig. 8c, which displays backlog in 
terms of mature demand, shows that for an A/F value of 
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Fig. 8. Time scries data for various values of A/F for experiment set la. 

200% the backlog can he as much as eight weeks of mature 
demand Backlog measured in terms of weekly mature de- 
mand is constant for low A/F. It increases for high A/F be- 
cause products cannot be shipped as fast as orders come in. 

Fig. 8d shows that the EOL RPI level falls as A/F inc reases. 
In addition, the general level of RPI as a function of lime 
falls as A/F increases until A/F is greater than 150%, when 
Ihe RPI level actually appears I" rise as A/F increases. The 
reason is that because of shortages we order more of all 



material to build the shortfall in units. The short lead time 
parts show up first, but cannot be used because of a short- 
age of the long lead time parts with minimal safety stock. An 
analysis of the results shows that the critical part is A.3. 

Fig. 8e shows that the WIP profile increases as A/F increases. 
This is expected, since WIP is directly related to the ship- 
ments Sowing through the system, and the shipments are 
directly related to orders, which are directly related to A/F 
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Remember that this is tnie only when the production capac- 
ity constraint is not reached. If production capacity is only a 
little greater than forecast, high demands would result in the 
level of W1P being capped at some limit but spread out over 
time. 

Fig. 8f shows lhal the FGI level is identical for all values of 
A/F less than LOOK. For A/F greater than 100% the FGI gets 
eaten away slowly because the rate of replenishment of new- 
units does not keep up with the shipments because of under- 
forecasting. However, sinc e FGI safety stock levels are based 
on two weeks of l:i-week average forecast and the forecasts 
used are identical in all the experimental runs, the peak FGI 
lends to be the same. 

Fig. 8g. on-order malerial, shows initial large spikes for 
material for RPI and FGI safety stock, followed by a drop 
after the material for safety stock has been delivered. Sub- 
sequently the profile shows an increasing level over time as 
A/F increases. 

Fig. 8h. materia] ordered, shows the same spikes before week 
21 that we have seen before. Again the malerial ordered 
versus lime increases as A/F increases. 

Fig. 8i shows that, in general, committed inventory afler 
week 21 is higher for higher A/F and stretches out farther 
over time. For lower A/F the committed inventory is lower 
in the early pail of the life cycle, but there is an increase in 
EOL inventory. 

Fig. 8j shows that for A/F less than 100%, Shipments follow 
the order si ream nicely, High A/F (high demand) values 
cause the initial orders to be filled as specified, bill subse- 
quently shipments drop off and then catch up. The product 
shipment over time is smooth when A/F is less than or equal 
to 100%. When A/F is greater than 100%, during the early 
part of the life cycle the orders are filled as they come in. As 
the FGI safely stock is consumed, the shipments fall lo the 
forecasted levels, and then subsequently tend to rise to the 
actual order levels. 

The on-time shipment graphs in Fig. Sk show that initial 
orders are delivered on time in all cases. For A/F less Ihan 
100% (forecasts are high), all orders are delivered on time. 
For A/F greater than 100% ( forecasts are low), initial orders 
are delivered on lime, but subsequent orders are late. As A/F 
increases beyond 100%, both the percentage and the total 
dollar value of on-time shipments ( and consequently deliver- 
ies), go down, and the late orders never catch up. On-time 
delivery graphs, which are not shown, Would be identical lo 
on-time shipment graphs shifted by one week. 

As expected, because of the policy of shipping as late as 
possible, Fig. 81 shows that average order-to-delivery time 
never goes below four weeks, bul increases with time up to 
18 weeks as A/F increases to 200%. Fig. 8m, showing the 
percentage of on-time deliveries, is consisteni with Figs. 8k 
and 81 in terms of on-time deliveries. 

How Late Are Late Orders? How laic are the laic orders and 
how many orders are delivered on time (namely, within four 
weeks of being ordered )? These questions are answered in 
Fig. 9, which shows the dollar volume of deliveries and the 
order-to-delivery time. For A/F less than or equal to 100% 
(forecasts high or demand low), all orders are delivered on 
time. For A/F = 10696, most orders are delivered on lime. For 



A/F = 160% and 200% (forecasts low), some orders are deliv- 
ered on time, and a large fraction of orders are delivered 
late. Furthermore, for high A/F values, even though the total 
volume of Shipments is higher, the amount of on-time ship- 
ments and deliv eries actually goes down. Some orders are 
delivered as much as 14 weeks late, that is, 18 weeks after 
receipt of order. This 14 weeks is the upper limit of lateness 
for this particular mode] and data configuration. No matter 
how high A/F gets, orders will never be later than 14 weeks. 
The explanaiion for this is given in Appendix IV-5. 

Interpretation of Results. In this model, forecasts w ere nol 
updated on the basis of orders. In reality, when orders are 
very much under or over forecasts, there will be pressure to 
change the forecasts. If further information on the forecast- 
ing process is available, this can be incorporated into the 
model. Another Study thai could be done is to see what hap- 
pens if we treat the initial orders as early indicators of the 
whole life cycle, that is, after some period of lime, we revise 
the forecasts so that they more closely represent the volume 
of actual orders. On the other hand, if the life cycle is very 
short, it may turn out that revising the forecasts when the 
first orders come in may nol have an impact on system re- 
sponse. We have established a nominal trapezoidal product 
life cycle, but this could be changed in various ways. Il 
could be stretched oul horizontally to increase the life cycle 
(as is done in subsequent experiments), or vertically, to 
show a higher level of product demand. 

Customers need lo receive the products within a reasonably 
short lime, or they might cancel the order. For the model, 
we assume that customers are willing to wail patiently as 
long as it takes for the manufacturing facility to produce and 
ship the products, and that they will not cancel the order. 

The purpose Of this detailed discussion is to show how 
changing the one factor, A/F, can have different impacts on 
different metrics, and how this might affect different parties 
interested in the outcomes. A/F is partly under the control of 
customers, and partly under I he control of marketing, as- 
suming that greater effort will provide a better estimate of 
orders. It shows that if A/F Ls low. order processing and 
shipping would have excellent performance metrics in get- 
ting products out in a timely fashion, whereas material pro- 
curement would be in I he situation of trying to explain why 
there is so much malerial in the plant, and marketing and 
the plant manager may have to explain why orders are 
below target. On the other hand, if A/F is high, customers 
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Fig. 9. Deliveries by order-to-delivery time in weeks for experiment la. 
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Table III 

Range of Values of Factors for Different Experiment Sets 



Factor Description 

Actual/Forecast, % 

Pan Safely Stocks 
Class A 4K weeks 
Class B 8K weeks 
Class C IRK weeks 

Life Cycle. L+6 months 

Availability, weeks 

Percentage value of 6. 10. and 
14-week lead time parts in the 
product (r%.s%.t%) 



Parameter Name 



A/F 



Number of 
Different Values 

11 



Values 



K 



L 
Y 
li 



'» 

6 
4 



A/F(%) = 5O.75.95.i00.1O5.11O.12O,125. 
150.175.200 

K = 0.5.0.75.7.0.1.5,2.0 



L = 0.3.6.12.18 
Y = 1.2,4,8,12 

rrr = ( 100.0.0).rst = (25.40,35), 
sss = (0,100,0), ttt = (0.0.100) 



E<petimerrt 0 (nominal easel Values shown m italics 

Experiment Set 1a luncomtollable factor A/F vanedl Values ol A/f varied as shown. Values of other factors same as experiment 0 

Experiment Set lb (A/F = 100"%. controllable factors vanedl' Values of factors other than A/F varied as shown in turn Values ol other factors same as in Experiment 0 
Experiment Set 2 (dual-factor experiments!. Values of factor A/F and one other factor varied m turn Values of other factors same as in Experiment 0 
Experiment Set F (all factors varied) Values of all live factors vaned as shown 



will be screaming for products, order processing and ship- 
ping will be trying to placate angry customers, production 
will be under pressure to put out products faster, and mate- 
rial procurement will have to explain the perpetual shortage 
of raw material A.3 while other material is piling up. 

Experiment Set lb: 

Controllable Factors Varied with 1 00% A/F 

We next look at the effect of changing the factors over 
which the manufacturing enterprise has some control. In the 
single-factor experiments, the varialion of each factor is 
summarized in Table III. Except for the set of runs where 
A/F varied as in experiment la. A/F was set at 100%. 

Changes in safety stock levels can be characterized in many 
ways — for example, for each pari individually. We chose to 
multiply t he safety stock levels of experiment (I by a con- 
stant multiplier K whose value ranged from 0.5 to 2.0. Life 
cycle lengths were changed by using values of I, to result in 
life cycle lengths L+6 bet ween 6 and 24 months. 

Availability Y was varied from 1 week to 12 weeks (it cannot 
be less than 1 week because of the 1-week shipment transit 
time). Y = 1 requires off-the-shelf delivery and implies a total 
litiild-io-forecast strategy. As Y increases, the production 
strategy shifts from build-to-forecast to build-to-order. From 
prior considerations, an availability Y of 18 weeks will result 
in on-time delivery of every order regardless of forec ast 
quality; 

While (here are different ways to characterize modification 
of pail lead times — for example, changing it for each part — 
we chose in change pari lead limes liy changing the i>cn Till- 
age of parts with lead limes of 6, 10, and 14 weeks to be 
100% in turn. 

E0L Results. The E( )L inventory graphs for A/F = 100% are 
summarized in Fig. 10. EGL inventory increases as safety 
stock increases; the results are consistent with experiment 
0. When K is 0.75. we carry 12 weeks of C parts and there is 
no Ei il. RPI When K is 1, we carry 16 weeks of C parts and 



end up with EOL inventory of C parts. When K is greater 
than 1. EOL RPI increases. When K is 2, we carry 16 weeks 
of B parts and EOL RPI includes both B and C parts. 

Fig. 10b shows that product life length has no impact on 
EOL inventory. This is to be expected in the model because 
increasing L stretches out the middle portion of the time 
series graphs, and the behavior towards the end of life tends 
to be the same in all cases when L increases (illustrated in a 
future graph. Fig. 1 lb). For short L, the effect of the rising 
demand in the beginning of the life cycle affects the behavior 
mi the end of the life cycle. Fig. 10c shows that as availability 
Y is shortened. EOL inventory increases, that is, (putting 
shorter lead times to customers exposes us to more risk of 
EOL inventory. This is intuitively correct; the longer the 
quoted availabilily. the longer we can afford to wait before 
Ordering material. 

Part lead time has no unpad on EOL Inventory when A/F = 
100% (Fig. Hid), 

Othei Results. Fig. 1 1 shows the inventory measures over 
time as different factors are varied- Delivery performance is 
not shown because for A/F = 100%. delivery is always 100% 
on time. 

Fig. 1 la shows the inventory measures over time as a func- 
tion of raw material safety stock multiplier K. The heights of 
the three initial spikes for material orders increase as K in- 
creases, directly impact RPI and on-Older material, and indi- 
rectly unpad on-hand and coiniuilied inventories, hi general, 
the higher the K, the higher the inventory levels, including 
EOL inventory, which is the tail of the committed inventory 
graph, The on-order material level before the start of pro- 
duction increases as K increases. Keeping all the other fac- 
tors constant, there Is no change in backlog or delivery 
performance, and these are nol shown in Fig. 11a 

Fig. lib shows the inventory measures over time for varying 
the product life cycle by changing L from 0 to IS months. 
This is one of the less interesling graphs, shown here for 



Uetfinbcr HUM HpwIetlPw-karrl Journal 95 



© Copr. 1949-1998 Hewlett-Packard Co. 





Y (Weeks! Il (% 6-week, % 10-week, % 14-week lead lime pans) 

to] W) 

Fig. 10. EOL Inventory by single-factor changes with A/F = 100% for experiment set lb. la i Effect of materia] safety stoek (5 runs). 
(10 Effeii of product life (4 runs), (c) Effect of availability (5 runs), (<l) Effect of lead time (4 runs), 



completeness. EOL inventory is the same in all cases. How- 
ever, because total PCFT increases. EOL Inventory is a 
lower percentage of PCFT as L increases. 

Fig. 11c shows the inventory levels over time for varying 
quoted availability Y. As Y increases, after the same three 
initial spikes, the amount of material ordered gels delayed, 
and the on-order material graphs get stretched to the right. 
The committed inventory graphs are also stretched into the 
future. The committed inventory is lower and the EOL in- 
ventory (tail of the committer! inventory graph) tends to 
decrease. The delivery profiles are shifted out into the 
future and the backlog levels are higher. 

Fig. 1 Id shows the time responses of the inventory metrics 
as part lead limes vary. Notice (he change in shape of the 
material ordered graphs, For II = (2:1.40,35), there are three 
large and three small spikes, whereas for the other cases, 
there is one large spike and one small spike. As lead time 
increases, the material needs to be ordered earlier. On-order 
material increases as the lead tune increases. On-hand inven- 
tory does not change. There is no impact on EOL inventory, 
order backlog, or on-hand inventory (RP1+WIP+FGI) as long 
as A/F remains constant at 100%. 

Interpretation of Results. This set of results shows how each 
organization in the manufacturing enterprise can improve its 
performance metrics assuming thai il relies on the forecasts 
given as being accurate and does not try to second-guess 
them. For example, if material procurement Ls under pressure 
to lower inventory levels, it would naturally try to reduce K. 
On the other hand, order processing and shipping would 
prefer to reduce Y to reduce having to deal with impatient 
customers. 



Experiment Set 2: Dual-Factor Experiments 

In this experiment set, we varied two factors in combination 
and attempted to observe the effects. However, instead of 
looking at all combinations* we looked at the impact of each 
of the other factors when A/F changed. This enabled us to 
see the effect of the controlled action in various situations 
of customer ordering behavior. 

Results of Two-Factor Experiments. Fig. 12 summarizes the 
information Oil BOL and on-time deliveries as A/F and Other 
factors are varied. Fig. 12a shows that as K increases, there 
is higher exposure to EOL inventory as A/F decreases. How- 
ever, increasing K in general gives belter delivery perfor- 
mance by Shortening the average order-to-delivery time as 
A/F increases above 100%. Below an A/F value of 10096, K 
does not have an impact on the already excellent delivery 
performance shown by 0% late deliveries. 

Fig. 12b shows that as L increases. I he total shipments for a 
given A/F increase. For long L, the absolute volume of on- 
lime deliveries initially increases as A/F increases. As A/F 
keeps on increasing past 100%, the absolute volume of on- 
lime deliveries decreases. The average order-to-delivery time 
is not affected very much by L. and the EOL inventory is im- 
pacted insignificantly. The absolute amount of EOL inventory 
seems to depend little on L except when L is 0. For L = 0, the 
long lead lime and high safety stock pails may actually cause 
most of the material for life cycle use to be ordered before 
the first customer order is received. The percentage of EOL 
writeoff decreases for a given A/F as L increases, reflecting 
the fact that the EOL writeoff is a smaller percentage of the 
tolal shipments as total shipments increase. 
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Fig. 12. EOl. and shipment metrics as liinclinns of A/F fnr experimeiil ser 2 as each of the other far-tors is varied, (a) K varied, (b) L varied, 
(c) Y varied, (d) II varied, 

Fig. 12c shows that increasing Y is desirable for reducing the in customers waiting for long periods of time, which in prae- 
percentage of late deliveries and reducing EOI. inventor.', but tice might lead to possible order cancellations. When Y = 1. 
that the average order-to-delivery time increases, resulting The worst average order-to-delivery time is lower than the 
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best average onler-to-delivery time when Y = 12 weeks. This 
is an example of a situation in which trying to reduce late 
deliveries by quoting a longer lead time actually leads to 
longer average delivery times and possibly lower customer 
satisfaction. 

Fig. 12d shows that if all other things are kept constant, 
longer vendor lead time leads to poorer performance when 
A/F is greater than 100*. and increased EOL exposure when 
A/F is less than 100%. For It = ( 100.0.0). that is. lead time for 
all parts is 6 weeks, A/F has little impact on average order- 
lo-delivery time over the given range. Furthermore, the per- 
centage of late deliveries is generally lower than for the 
other \-alues of lead time. If Y could be set to 12 weeks for 
the case It = ( 100.0.0 ). no orders will ever be late, regardless 
of the value of A/F. Applying reasoning similar to that on 
page 82. the policy of waiting for customer orders to arrive 
before we order parts c ould lead to an order-to-delivery time 
of nine weeks, which is shorter than 12. 

Observations. We have looked at the interactions of A/F with 
the other factors in our experiments and noticed the com- 
plexity of the interactions. Hie results of experiment set 2 
show the impact of uncertain customer behavior on various 
organizations Within the enterprise. In an uncertain world 
where A/F is outside our control, it would appear that in- 
creasing K and L reducing It. and increasing Y would in- 
crease on-time deliveries, which is desirable from the point 
of view of the manufacturing enterprise. However, increas- 
ing Y will tend to increase order-to-delivery times and back- 
log volumes, which could potentially lead to poorer cus- 
tomer satisfaction and high backlogs for order processing 
and shipping to deal with. 

The other problem of taking these actions is that while 
delivery performance for the enterprise improves in general, 
different people and organizations are responsible for in- 
fluencing and setting the values of K. Y. and It and obtaining 
the reward of improved metrics. Increasing K results in bet- 
ter availability but increased write-off. especially if A/F is 
below 100%. One individual owns K. another individual owns 
Y. the vendors and R&D together determine It. marketing 
owns L, and customers determine A/F. Any one of these can 
influence the other measures unilaterally, so it is necessary 
to coordinate the efforts of increasing some parameters and 
reducing others simultaneously. For example, material pro- 
curement could reduce K on the assumption that it will re- 
duce RPI, committed inventory and EOL inventory, and this 
would be correct if A/F were 100%, but if .VF came in 
greater than 100%, the overall delivery performance would 
be poor. On the other hand, if R&D chose longer lead time 
parts because vendors demanded a premium price for short 
delivery times. EOL inventory would tend to be higher re- 
gardless of what value of K was chosen by material procure- 
ment. If quoted availability Y were reduced from 1 weeks to 
1 week, inventory levels would tend to go up. 

We could also consider the effects of the four other factors 
on one another, and that would give rise to another six com- 
binations. These discussions are outside the scope of this 
paper. 

Experiment Set F: All Factors Varied 

In experiment 0, we looked at the results of one simulation 
run. In experiment 1, for each factor we looked at four to 



eleven runs. In experiment 2. we looked at 44 to 56 runs for 
each combination of A/F and the other factor. As we study 
the effects of multiple factors, the number of runs increases 
exponentially. Complexity increases not only in terms of 
number of simulation runs considered but also the way in 
which we analyze the data. A full factorial experiment, that 
is, one in which all the factors are varied in all combinations 
given here, requires the analysis of 5500 runs. While it is 
easy to specify different levels of factors, the analysis of the 
amount of data generated as a result of increasmg the num- 
ber of factors becomes intractable. For example, if all of the 
time series graphs of a single run were plotted on one sheet 
of paper each, we would have a pile of printouts eleven 
reams of paper thick To do the analysis, we used a graphing 
technique supported In S-Plus called a design ploLt 

Design Plots. Fig. 13 shows the design plots of the means of 
each of four different metrics at each of the lev els of the five 
factors. The four metrics are EOL inventory- EOL inventory 
percentage, total on-time deliveries, and percent on-time 
deliveries. Each plot reflects one metric and summarizes the 
value of that metric for 5500 runs. The point labeled A is the 
mean of the EOL values of all experimental runs with A/F = 
50% (mean of 500 values), A longer line indicates greater 
sensitivity of the metric lo Uiat factor ov er the range consid- 
ered, all other things being equal. For example, -VF appears 
to have the strongest impact on EOL inventory, EOL per- 
centage, and on-time shipments. On the other hand, the ma- 
ture demand period L has a strong influence on the total 
dollar volume of on-time product deliveries. 

An interesting point is that mean EUL and EOL percentage 
decrease steadily as A/F increases. On-time deliveries in 
dollars increases up to a point as /VF increases to 125%, but 
subsequently decreases (point B in Fig. 13c). The explana- 
tion is that the safety stock policy gives some protection for 
on-time delivery in dollars when VF> 100% t In-time delis 
eries as a percentage remains at 100% for A/F s 100% and 
subsequently decreases as VF increases over 100% (point H 
in Fig. Ltd). 

Another interesting behavior is that of the points marked C 
and I). The fact that the mean v alues of the metrics appear 
close together for the (25,40,35) case and die (0.0.100) case 
suggests that the length of the maximum lead lime of parts 
in the bill of material has a veiy strong influence on on-time 
deliveries if all other factors are kept constant 

Further Analysis. We hav e barely scratched the surface of 
what is possible in analyzing the simulation data of litis one 
level bill of material, single-product situation. Further analy- 
sis and display of the variables is possible through scatter 
plots of pairs of variables and responses, and the use of fac- 
tor plots which show greater detail. Foi example, further 
analysis could try fitting a statistical model using least sum 
of squares of residuals for the responses, separately and 
jointly. This was not done for this paper. 

Experiment Set M: 

Multiple Product Life Cycles with Part ('onuiionalit) 

This set of experiments showed the impact of part com- 
monality across multiple product life cycles. The product 

1 We call it a design plot because it is generated by lhe S-Plus function plut dosign there is no 
standard name nl tins Blot In the literature 8 rt is relerred to as a a plot ol the mean response 
lor each level ol each lactor " 
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Fig. 13. Design plots for experiment set F: all five factors varied (5500 runs). 



cycles overlapped in time, that is, one started before the 
preceding one finished, and we looked at a series of scenar- 
ios (hat differed in the values of common pails in adjacent 
products. These were the assumptions: 
There were four products: Adder-1, Adder-2. Adder-3, and 
Adrier-4. 

Part commonality occurred between adjacent products only. 
Demand increased 30% for each new protlitcl. 
The unit cost of each product was 85% of (he unit cos( of 
the previous product 

Each product life cycle was 6 months, or L = 0. This means 
thai (he complete cycle for each product is (i months, or 24 
weeks. 

There was a one-month overlap between products, that is, 
(he first month of demand of a new product begins in the 
last month of demand of the previous product. This implies 
a total Lifetime Of the product family of 21 months, or 84 
weeks. 

Other factors and conditions remained as in the nominal 
case. 

Fig. 1-1 shows a graphical representational of the pan 
commonality between adjacent products for the different 
experiments. In particular, since part commonality for ex- 
periment M-0 is 0% across adjacent products, (here are no 
shaded areas. A fuller discussion of part commonality is 
given in Appendix III. 

Fig. 15 shows the forecasted and aciual order patterns for 
(he four products. 



Fig. 16 shows the RPI levels for pails used in the different 
products in Experiment M-0 (no part commonality). Con- 
signment inventories are not shown lo avoid clutter in the 
graphs. The WIP, KG I, products ordered, PCFT and delivery- 
profiles are identical for all runs in experiment set M. How- 
ever, each of (he runs has a different profile for RPI. Note 
(he EOL inventory of each set of parts. 

Fig. 17 shows the consignment and EOL Inventory levels for 
each run. As expected, the consignment level increases by 
prodtict because the forecasted and actual orders increase 
by product The consignment value for a particular product 
is the same across experiments. The EOL inventory for 
Adder-4 is the same in all (he experiments. There does not 
appear to be arty correlation between pail commonality and 
the EOL inventory. A correlation exists between pail ob- 
solescence for a product and the EOL inventory for that 
product. 

Fig. 18 shows the part obsolescence across products for each 
of the experiments. Notice how the EOL for each product in 
Fig. 17 is proportional to the obsolete parts for each product 
in Fig. 18. 

Traditionally, in considering part commonality, design prin- 
ciples suggest using as many parts as possible from the old 
product. However, the results above sugges( (hat from the 
point of view of EOL inventory, the amount of leftover mate- 
rial at the end of each product is proportional to the percent- 
age of the part value of the obsolete parts in the old product. 
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Fig. 14. Pan commonality be- 
tween products across experiment 
set M. Demand (width of bars) 
for each product is 30% higher 
than for tlte previous product 
Unit cost (length of bars) is 85% 
of previous product cost. 



Ii fun her suggests that the important consideration from the 
point of view 7 of EOL inventory is that the percentage value 
of obsolete pans at the end of each product's life should he 
minimized. 

Discussion 

In this section we discuss specific results of the Simple 
Model, enhancements to ihc EMS system to do more de- 
luded analysis, the role of the Simple Model in enterprise 
modeling and simulation, and optional ways of using 
enterprise modeling and simulation. 

The major results can be summarized as follows: 
Rational material ordering and safely stock policies designed 
to reduce inventory to zero at the end of the product life 
cycle can give rise to leftover material if customers orders 
exactly accorditig to forecasl. 

System behavior and the impact on differenl metrics such 
as write-off. delivery limes, and performance deliveries can 
be quantified with respect to (tie factors of forecast quality, 
safety stock levels, material lead times, product life cycles, 
and quoted availability individually as well as in combination. 
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Fig. 15. Orders for different product* for experiment set M. 



• Forecast quality, which is influenced by the external environ- 
ment, has a major effect on the metrics of interest For ex- 
ample, high inventory levels may occur when actual orders 
come in too high or too low. 

• The influence of part commonality on write-off can be 
quantified; this suggests an alternative way of looking at the 
practice of using common parts in a series of products. 

Whal have we learned from the simulation runs on the Simple 
Model? We have derived a set of specific insights into system 
behavior under a variety of operating conditions using a 
methodology of generating behavior over time. We went 
through a large number of scenarios and showed how to 
gauge system behavior from the perspectives of different 
parties. 

Interpreting the Results 

The model results are sensitive to the underlying assump- 
tions. Since we assumed the vendors always delivered on 
time in the simulation, the safety slocks in effect guarded 
only against demand uncertainties. We examined in detail 
Ihe situation of order forecast bias with zero variance. This 
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Fig. 16. RPI levels for the differenl purls as a fund ion 'if lime for 
experiment M-U (no pari commonality). 
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Fig. 17. Consignment and EOL inventory by product for different amounts of part commonality for experiment M-0. 



is not an inherent limitation of the model, but reflects only 
the deterministic circumstances in which we ran the simula- 
tions. However. I he results indicate that even if production 
and supplier lead limes are completely predictable and sup- 
pliers deliver on schedule, interactions and delays within the 
system lead to long lead limes being seen by the customers 
when there is underforeeasting of customer orders. The 
manufacturing enterprise needs to take this into account 
and start looking elsewhere — merely making the production 
faster and more efficient is not sufficient 

The results so far have only scratched the surface of the 
analysis and inlerpretalion possibililies. Other analysis 
could be done by varying ship times. FGI safety stock levels. 



production planning frequency, material ordering frequency, 
order filling policies, and uncertainty and lime delays of infor- 
mation flow. This increases the number of runs and the quan- 
tity of data collected as well as the complexity of analysis, 
but would provide a richer set of relationships. 

The Simple Model example may have left I he reader with 
the impression thiil the current KMS system can deal with 
only simple or trivial cases. One goal of enterprise modeling 
and simulation research activities is to address successively 
more complex interactions and to model real-world intrica- 
cies more closely. In support of that goal, the folio whig sec- 
tions discuss subsequent and future enhancements to deal 
with other issues that have been raised. 
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Fig. 19. Material and order flow 
diagram of a simple multientity 
distributed enterprise 



Uncertainty and Variability. In the experiments described, the 
Simple Model was run under deterministic circumstances. 
Demand values and process times were constant across a 
particular run for convenience of understanding, and we 
considered uncertainty in the form of forecast biases where 
demands were a fixed multiple of forecasts over the period 
of the forecasts. Other forms of uncertainty could include 
the actual life cycle being different from the forecasted life 
cycle. Uncertainly in process times could be handled by 
using two values for process limes: the planned process 
time for planning purposes and the actual time for execu- 
tion. This reflects the situation when actual process times 
are uncertain and different from the estimated limes for the 
process. For example, the build time for planning purposes 
could be two weeks, but it could turn out that the actual 
build lime was one or three weeks. 

We did not deal with variances that might occur when the 
total demand is forecasted accurately but the week-to-week 
demand fluctuates widely. Furthermore, variances of process 
limes (e.g., delivery limes from vendors and assembly times), 
yields (e.g., defective units), and build limes for individual 
units were nol modeled. 

Dealing with variances is fairly straightforward once they 
are characterized, It requires using random number genera- 
tors and multiple rims starling with different random num- 
ber seeds — ihe current practice of discrete event simulation. 
There are three primary costs associated with Ibis: Ihe in- 
crease in data collection lo characterize the variances of 
different processes, the increase in computational effort, 
and the increase in analysis effort. Only Ihe data for the 



model needs to be changed to reflect variances. The model 
structure itself requires no changes. 

Distribution and Multisite/Multiorganizational Interaction. The 

product distribution function and interaction between multi- 
ple sites were not considered in the Simple Model. Multisite 
and multiorganization interactions have been implemented 
by enclosing cloned versions of a slightly enhanced manu- 
facturing enterprise model as shown in Fig. 19. The enhance- 
ment requires the manufacturing facility to generate and 
transmit its projected material requirements in addition to 
material orders. 

Capacity and Supply Limitations. In current practice, build 
plans and material plans are sometimes computed ignoring 
production capacity and vendor limitations. In some cases, 
these plans are adjusted to conform to production capacity 
and Vendor supply constraints, such as a minimum order 
quantity or a maximum that can be ordered in a period. In 
other cases, these limitations are observed at phut execution, 
that is. at production, or when deliveries are not received 
front vendors when expected. There is no unique way of 
dealing with these limitations. 

Implementing capacity limitations in the current Simple 
Model is straightforward during production. To deal with it 
t luring planning requires the inclusion of two classes of ca- 
pacity constraints in the production planning algorithms: the 
Capacity rettttiCtioiJS tor ail individual product, assembly, or 
subassembly as well as total capacity, and the rate at which 
product ion capacity can increase. 
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In reality, when prospective capacity limitations are detected, 
production and manufacturing line design and engineering 
considerations determine the rate of capacity expansion. 
When gross overcapacity is detected, consideration is given 
to reducing costs by reducing capacity. While currently the 
EMS system cannot model the strategic decisions of 
whether to expand capacity or forego extra orders, it can 
model the consequences of picking either of these actions. 

Interaction of Multiple Products. The Simple Model assumed 
a single product with unconstrained production capacity. 
Consequently, a single unavailable part stops production of 
that product. Since this phenomenon also occurs with multi- 
ple products with no common parts, multiple products with 
no common pails can be analyzed by adding up the effects 
of the individual products separately. The reader familiar 
with linear systems will recognize this as the principle of 
superposition. 

Adding up the residts would also be valid for multiple prod- 
ucts with common parts with no part shortages as in experi- 
ment set M. It would not be valid for multiple products with 
common parts, resources, and supply and production capac- 
ity limitations under scarcity conditions. When a pail or 
resource is in short supply, decisions must be made on how 
to allocate the pails and resources based on some simple 
heuristic or optimal allocation scheme. 

Multilevel Bills of Materials. The Simple Model dealt with a 
single-level BOM. Further expansions allow an arbitrary 
number of levels of BOM to be passed as data to the model. 
A seven-level BOM for a real product has been implemented 
and tested successfully. This capability to pass BOM as data 
allows us to make different runs with different product 
structures (as for example in experiment set M) without 
modifying the model structure. 

Connection to a Mathematical Programming or Optimization 
Package. The Simple Model focused on applying simple algo- 
rithms for planning, The production planning and material 
procurement processes were initially implemented as die 



explicit closed-form solutions derived in Appendix L It was 
realized subsequently that these algorithmic closed-form 
solutions were the solutions to the linear programming 
problem formulation. As more sophisticated planning deci- 
sion techniques are proposed and studied, Implementing the 
algorithmic solution for each new technique becomes im- 
practical. An alternative approach is to formulate the plan- 
ning process as an optimization problem and separate its 
solution from the formulation. This leads to concentrating 
on ways to better formulate the problem, leaving the solu- 
tion to a separate process such as a mathematical program- 
ming package. This could provide a means of rapidly testing 
alternative strategies for production planning (e.g., global 
production planning across the entire enterprise versus 
local production planning at each site). 

R&D, Marketing, and Cash Flow. Fig. 20 shows a proposed 
enterprise model at a broader scope for the next level of 
complexity. It generalizes Fig. 3 which focused mainly on 
manufacturing activities. Modeling the marketing function 
(and associated activities such as the forecasting process, 
pricing issues, and product obsolescence) could help show 
the impact of marketing decisions and activities on the over- 
all system response as well as the impact of using current 
orders to project future forecasts. Modeling the R&D func- 
tion could provide insights on impacts on time to market, 
with product development time taken Into account in addi- 
tion to build time. Modeling these functions can help us deal 
with situations that require coordination of marketing. R&D, 
;uid manufacturing activities and can help identify the exis- 
tence of leverage points for process improvement. The 
blocks shown in the diagram represent functions, and each 
could describe multiple instances of that function. For ex- 
ample, the block labeled manufacturing could represent 
multiple manufac turing sites interacting with one another. 

The primary flow-s in the Simple Model concentrated on infor- 
mation (e.g., orders, forecasts, plans, and status information), 
material, and control (e.g., triggers that cause activities like 
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production to start). Flows and inventory levels were con- 
verted to monetary units before being analyzed, but cash 
flows were not modeled explicitly. 

Modeling cash flows for payments of parts, products, and 
process costs will provide a financial perspective. Showing 
projected cash flows and investments and the projected 
financial consequences of investment decisions will provide 
the stepping stones to doing discounted cash flow and net 
present value analysis. Modeling cash flows will also help 
generate pro forma financial statements to estimate reve- 
nue, cost, and income owing to different capital budgeting 
and allocation decisions, and provide a tool that could help 
address business issues. An example of such an issue is the 
transition from a high-margin business to a low-margin high- 
volume business. 2 " 1 The model may help by projecting cash 
requirements for investments and operations and providing 
estimates for return on assets during the transition. 

Whither the Simple Model and the EMS System? 

The Simple Model is not an end or final model; it is inter- 
mediate in a series of models that have contributed to the 
evolution of enterprise modeling and simulation (see page 90) 
and the development of the EMS system. Its simulation dem- 
onstrates the kinds of results that can be generated by enter- 
prise modeling and simulation. Its value is in providing greater 
Quantitative analysis where previously qualitative approaches 
have been adequate (see below). Its immediate subsequent 
application was the planning calendar model. 25 26 ' 27 

The subsequent and future enhancements discussed make 
the Simple Model more complete. Some of the changes 
make the model larger, add detail complexity, and generate 
more precise results. Other changes broaden the scope of 
the model, and make it more representative of the other 
functions of the enterprise besides manufacturing: these 
changes require the addition of greater levels of abstraction, 
the ability to consolidate different points of view, and knowl- 
edge acquisition across the organization. All the changes are 
technically feasible and require different kinds of activities: 
the first set of changes requires greater emphasis on "model- 
ing in the small," and the second set requires greater empha- 
sis on "modeling in the large" (see discussion on page 81). 
Discussions based on the experience and views of some 
managers responsible for operations suggest that expanding 
the size by increasing the detail complexity, while providing 
greater predictability of the system, is difficult and requires 
a tremendous amount of investment to manage the complex- 
ity of the models and the generation and interpretation of 
the resulting data. Monroe 2 * 1 and Harmon 2 * have individually 
recommended that there is greater value and potentially a 
far greater rctiun on investment to be obtained by broaden- 
ing the scope of future models to address and reflect business 
issues and concerns. 

Regardless of the direction of model enhancement is the 
challenge of managing simulation data. The simulation runs 
for the experiments generated large amounts of data, and 
only aggregate data was collected and summarized. For in- 
stance, RPI levels for every part were generated for each 
week during the simulation, but the data collected was the 
aggregate dollar Value of all the parts. The challenge became 
one not of collecting all data, but one of deciding ahead of 
time which data was interesting and not collecting that 



The Simple Model: Sponsor's Perspective 

As HFs Compute/ Systems Organization customers increasingly reauest delivery 
of complete systems with much shorter lead times, our design, manufactunng and 
delivery svstems are being stretched beyond their performance limits. 

Qualitative approaches to improvement have served us well in the oast. Out mote 
quantitative analysis is needed to understand and improve the total system both 
from a customer and an HP perspective 

The Simple Model was conceived and developed in teamwork with HP Laborato- 
ries. We sponsored n to help learn and communicate the key drivers and charac- 
tenstics of a manufactunng enterpnse The insight achieved could then be used in 
our order fulfillment initiative to design product, manufacturing, and delivery 
systems to match critical business requirements and position us to meet future 
customer needs effectively in the global marketplace 

Jerry Harmon 

General Manager 

HP Puerto Rico 

Sponsor of Simple Model 

for HP Computer Manufacturing 



which was not; otherwise the storage requirements for stor- 
ing all the generated data became significant. The data pre- 
sented in the form of graphs and charts in this paper is only 
a small portion of the actual data collected and analyzed. A 
larger amount of collected data was discarded because it did 
not look interesting. 

The sheer amount of detailed data that needs to be examined 
and interpreted tends to overwhelm the analyst. The analysis 
and interpretation of the data was very much a creative team 
effort requiring much discussion, and is not yet understood 
well enough to be automated. As we increase the number of 
factors, the behavior becomes more complex, and the 
amount of data tends to increase exponent hilly with the 
number of factors. When presented with the data in its raw 
form, decision makers and experts familiar with the problem 
issues but less familiar with modeling and simulation ail have 
the same general reaction (hat it is too complex and difficult 
to understand. While this is a valid reaction, the reality is that 
the enterprise is a complex system of interacting information, 
material, resource, and control flows, and whether we like it 
or not, has complex behavior. Enterprise models as abstrac- 
tions or idealizations for the real system merely reflect that 
complex behavior in the simulation. We can choose to ignore 
the complexity of the real system and use ad hoc qualitative 
methods to deal with the resulting behavior, or we can 
choose to face the complexity, understand it by selecting 
what we think are important factors that influence the be- 
havior of the enterprise, and rind opportunities for applying 
the understanding. Enterprise modeling and simulation rep- 
resent one means of facing this complexity and providing an 
understanding of this behavior. As with most endeavors, we 
have found that the precursor to simplicity of expression is 
greater depth of understanding. 

Increased technology in the hands of the modeling and simu- 
lation expert is not sufficient for providing the insight that 
will help make better decisions and highlight important re- 
sults. Merely generating large numbers of insights and conclu- 
sions is insufficient. It requires the perspective (if operations 
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teams and derision makers to guide the direction of explora- 
tion and to emphasize die correct metrics to solve the current 
situation. In fact, Monroe 24 has suggested, and we in the 
enterprise modeling and simulation project concur, that 
techniques to digest and present large amounts of data rap- 
idly and in a more easily understood fashion would he a 
beneficial next step and a fruitful area of research, and thai 
joint work of a modeling expert with an operations team to 
further understand the issues of data reduction, interpreta- 
tion, and presentation will help modeling and simulation 
take its rightful place as a useful tool in analyzing business 
decisions. 

The Simple Model is a descriptive model that illustrates 
complex dynamic behavior of a manufacturing enterprise 
with low structural and detail complexity. As we have seen 
in this paper, its primary output is data and information on 
the state of the world, and it goes a great distance towards 
presenting observations. I'nlike an optimization model, 
which Ls a prescriptive model whose solution recommends 
the best action under a given set of circumstances, the Simple 
Model does not suggest actions. It is up to the analyst or deci- 
sion maker to come up with creative solutions to solve the 
problems highlighted by observations of the model behavior 
and then assess the results from a subsequent simulation 
run incorporating those solutions. 

Prospective Applications 

Let us now look at application areas for enterprise modeling 
and simulation. These include but are not limited to improv- 
ing the performance of the current system (continuous im- 
provement), studying the impact of reducing process times, 
and generating information for the enteiprise, all of which 
are discussed below. A potentially f;u" more powerful appli- 
cation is looking at new designs where the process itself is 
being changed (i.e.. reengineering). Because of the strong 
current interest, large impact, and controversy surrounding 
reengineering, this subject is given its own discussion on 
page 86. 

Incremental Improvements. Actions for continuous improve- 
ment can be suggested by running the nominal or baseline 
model and rerunning it with minor modification and changes 
in par ameters or actions over which we have control. For 
example, it may not be possible to reduce all the pan lead 
limes down to six weeks, but we could certainly see tire 
impact of reducing the value of 14-week parts in the product 
to determine the impact on the metrics of interest. We could 
look at the impact of reducing build times or FG1 safety 
stock levels slightly to study the impact on the measures of 
interest. We could examine the impact of making two small 
changes at the same time. This application of enterprise 
modeling and simulation supports the process of continuous 
improvement by demonstrat ing the benefits of small 
changes. 

Verifying Impact of Reducing Process Times. Davidow and 
Malone 2 -' talk about how short cycle times attenuate "the 
trumpet of doom," which is a plot of forecasting error versus 
time that implies that the further a person must forecast into 
the future, the greater the possibility of error. Rather than 
speculate on or guess on the impact of this trumpet of 
doom, enteiprise modeling and simulation provide a way to 
quantify the effect of reducing system cycle times. This can 



be accomplished by making some estimates of the amount 
of uncertainties within the model. 

Stalk and Hout :i " suggest mapping out explicitly the major 
causes of problems in processes such as new product devel- 
opment or in operations, and comparing actual versus stan- 
dard cycle times. These maps provide qualitative relation- 
ships. To the extent that processes can hie mapped explicitly 
and quantitatively, enteiprise modeling and simulation can 
show how the system behavior changes for a given change in 
the process and can verify whether modifying the component 
processes has the desired overall global effect. 

Generating Enterprise Behavior Information. Davidow and 
Malone-" identify four categories of information of use to a 
corporation: content, form, behavior, and action. Content 
Information is historical in nature and reflects the experi- 
ence. Form information describes shape and composition 
and is usually more voluminous than content information. 
Behavior information often begins with form information 
and usually requires a massive amount of computer power 
to predict behavior through simulation. They suggest that 
the final triumph of the information revolution will be the 
use of action information — information that instantly con- 
verts to sophisticated action. Until recently, only the most 
elementary category, content, has been available to business 
in any systematic and manageable way, and obtaining or 
generating the other three categories has become economi- 
cally feasible only in recent years. They go on to describe 
how behavior information generated by computer simulation 
is the new paradigm for product design ranging from molec- 
ular design through automotive design to airplane design. 
With such behavior information design disasters of the past 
might be averted, and potential and unforeseen future trag- 
edy can be replaced with a successful and predictable con- 
clusion. With the arrival of workstations In the 1980s, it be- 
came reasonable for the computer to create realistic models 
and put them through their paces rather than painstakingly 
building prototypes and testing them under a variety of op- 
erating conditions. High-speed simulators could be built that 
reproduced the actual electrical characteristics of devices in 
different configurations. 

We suggest that enteiprise modeling and simulation repre- 
sent an assistive and enabling technology for the design and 
implementation of processes of the enterprise, and that the 
application of such techniques to the enterprise could poten- 
tially have greater impact than product design. Furthermore, 
these techniques have the characteristic of converting con- 
tent and form information into behavior information on 
which action can be taken. While the enteiprise modeling 
and simulation process currently does not suggest actions 
or alternatives, it describes the behavior of the system de- 
signed with alternate processes under different operational 
scenarios. 

Conclusions 

In this paper, we outlined activities in enterprise modeling 
and simulation at HP Laboratories and presented in detail the 
results of the simulation of a simple model of a manufactur- 
ing enteiprise. We have also described possible areas where 
enteiprise modeling and simulation might be applicable, and 
reiterate that enterprise modeling and simulation provide a 
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way of quantifying the impacts of proposed changes before 
they are implemented. 

The Simple Model captures the characteristics and behavior 
of a manufacturing entity at a fairly high level. It shows that 
in the best of circumstances (e.g.. customers ordering ex- 
actly according to forecast), seemingly rational operational 
policies can lead to end-of-life inventory. The situation only 
gets more complex as greater uncertainty is introduced, 

Experience with using the Simple Model suggests two direc- 
tions for future research in enterprise modeling and simula- 
tion. The first is to expand the scope of the Simple Model to 
more completely represent the functions and organizations 
and their interactions in the enterprise. The second is to 
improve the process by which the data generated by the 
simulation models c an be understood and summarized, and 
the resulting information presented in a form that permits 
decision makers,! o understand more completely and to act 
more rapidly and with greater assurance that the desired 
objectives will be achieved. 
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Appendix I: Mathematics of Production and Material Planning for the Simple Model 



1-1 The Planning Function 

The planning function is actually an analytic model embedded within a discrete 
event simulation model. The fundamental principle on which the production and 
material planning algorithms are based is the conservation of mass, that is, con- 
sumption cannot be higher than the total supply available. The order in which the 
build plan computation is done is the reverse of the order in which subassemblies 
are built and products are shipped (i e , from shipment to product build to pari 
order). For ease of explanation, the current week is considered to be week 0. This 
derivation emphasizes clarity of explanation rather than rigorous detail 

There are three sets of decision variables to be determined for each week: sit), the 
shipment plan, bill, the build plan, and mft), the material ordering plan These are 
shown in italics 

Before we get into the mathematical formulation, let us first look at the process of 
computation. Fig 1 illustrates how the production and material planning algorithms 
work in this model The computational process is described in the following order 

• 1-2 describes the notation shown in Fig. 1. 

• 1-3 describes the safety stock computation. 

• 1-4 describes the initial conditions for computation 

• 1-5 describes the computation of the shipment plan. 

• 1-6 describes the computation of the build plan 



• 1-7 describes computation of the number of units started this week 

• 1-8 describes the computation of the material consumption and material ordering 
plans. 

• 1-9 describes the actual material ordered this week. 

• 1-10 describes the computation of the number of weeks for each of the plans. 

1-2 Notation 

• n, s, t = indexes for week number (current week = D| 

• fltl = Current forecast of product oiders for week t, t = 0, 1 Ni 

• Rt) = FGt at end of week t 

• W|tl = WIP at end of weekt 

• Bit) = Backlog units at end of week t 

• Bits) = Backlog units at end of week t having shipment dates in week s 

• sM= Planned shipments during week t 

• tilth Units planned to be started during week t 

• B = Build time in number of weeks 

• Y = Quoted availability in number of weeks 

• S = Shipment or transit time 

• j = Index relating to part 

• 0, = Quantity of part j per unit uf product 

• qjlt) = Planned consumption of part j during week t 



Manufacturing 
Enterprise 



Orders 



WI-11 




Forecasts 



Production 
Planning 
Material 
Planning 



Orders 




"H 1 RPI WIP FGI 



Forecasts 
I 



Production Planning 
Material Planning 



This 
Week's • 
Orders 



Material 
Planning 



Material 
Plan 




Production 
Planning 



Weeks of I Quoted 
FGI I Availability Y 
W I Transit TimeS 



Part Lead 
Times 
Li 



RPI Safety Stock 
j Riltl 
M 



Backlog 
B(-1) 



FGI Safety Stock 
Rt) 




Build Plan 



Rj(-1) 

Note: Subscript i indicates Vj~ J. 



1 



This Week's Build 




W(-1) F(-1| 



Fig. 1. Natation and production/material 
planning. The shipment plan is computed from 
the backlog, forecasts, quoted availability, and 
transit time. The build plan is computed from 
the shipment plan, the build time, WIP. FGI. 
and FGI safety stock. The actual build is com- 
puted from the build plan and the material 
availability. The material consumption plan is 
computed from the build plan and the bill of 
materials. The material ordering plan is com- 
puted horn RPI. RPI safety stock, the material 
consumption plan, on-order material, and lead 
time 
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• njft) = Plann6(J quantity of material j to be ordered during week 1. i = 0. 1 N,. 

jeJ 

• R,|tl = RPI of part | at the end of wee< I 

• tfX) = Units of part ] received during week t 

• 0/lt) = Units of part j on order ai the end of week t 

• L, = Vendor lead time for pan i 

• J = Set of parts that go into the product 

• w ■ f Gl safety stock in weeks of demand 

• V, = RPI safety stock of pan j in weeks of demand 

• N s = last week for computing shipment plan 

• Nq = Last week for computing build plan 

• Nf = Last week used for forecasts 

• N, = Last week for computing material order fc part i 

Since the current week is 0, the values of these variables represent actual values 
for weeks before 0. and the values are computed, set or derived for weeks 0 and 
later In particular, the values of variables at the end of week -1 represent the 
current values of those variables, as described in I-4 All numerical Quantities 
except time indexes are zero or positive 

1-3 Safety Stock Computation 

Safety stock is expressed in number of weeks of 1 3-week leading average forecast 
The 13-week leading average forecast at the end of week t is defined as 



13 

«t| = -^X f " + 11 

i = 1 



ID 



The target FGI safety stock at the end of week t is w weeks and the target RPI 
safety stock at the end of week t for part | is V, weeks. The expressions for these 
quantities are: 



Rt| = wfft) 
R,(t) = VjQji 



12) 
(3) 



Minimize sfnl, n = 0.1 N, 

n n-iY-Sl 
suchthat Vsft/a £ BI-UI + Y fill 

te(ihsn) 



1 = 0 



and stnl > 0 



• = :■ 



These equations define 3 series cf IN. » 1 1 linear programming problems however 
this formulation will always return a set of feasible solutions, and the optimal 
feasible solutions can be expressed in closed form as follows 



s(n) =•< 



V 8-l.s) for n = 0 

S=w|lS0) 

BM.nl forO<n<Y-S 

f|n — (Y — S)| for n > Y - S 



151 



The term (Y - S) is the difference between the quoted availability and the transit 
time li e , the order-to-ship time to achieve on-time delivery), and indicates the 
time in the future after which shipments depend solely on forecasts 

1-6 Build Plan 

The build plan, which indicates how many units are to be started in the current 
week 0 and succeeding weeks, is based on the assumption that the FGI levels at 

the end of weeks 0.1 B-l have already been determined by the current FGI. 

WIP. and shipments preceding week 0 It further assumes that we might be able to 
control FGI at the end of week B or later by deciding how many units we start this 
week and future weeks, that is. bv controlling bt0),blV,....b{nl We want to keep 
the Wn/as low as possible but greater than or equal to 0, such that the total planned 
build during weeks 0 through n must be greater than or equal to shipments during 
weeks 0 through B+n plus FGI at the end of week B+n minus current FGI and WIP 
The complete formulation is as follows: 

Minimize oYnAn = 0.1 N& 



B(-D= £? 



I-4 Initial Conditions 

• fl-1 ) = Actual FGI at the end of the previous week, that is. current FGI 

• WI-1 1 = Actual WIP at the end of the previous week, that is, current WIP 

• 0||-1 1 - Actual part | on order at the end of the previous week, that is. current 
on-order material 

. R ( H | = Actual RPI for part j ai the end of the previous week, that is, current RPI 
for part j. 

• B|-l| = Order backlog in units at the end ol the previous week, that is, current 
backlog: 

1-1. si (41 
it all shipment dales in current backlog,: 

• B(-I.s)= Component of current backlog with shipment date in week s. 
1-5 Shipment Plan 

The shipment plan indicates prospective shipments during the current and future 
weeks It is computed on the assumption that customer orders are not shipped 
belore they are due. but are shipped in time to satisfy the quoted availability 
requirements This implies that for any week, the orders planned to be shipped are 
those that are already late lie. should have been shipped in an earlier week) and 
those that must be shipped to be delivered on time Notice that in computing the 
shipping plan, we do not lake into account the amount of inventory on hand or in 
process This is representative of the way shipment plans are computed and then 
subsequently checked against reality. 

Put another way. this can be expressed as planning to ship the minimum quantity 
in each week that will satisfy the quoted availability criteria The problem can be 
formulated as shown in the set of equations below, which indicate that we are 
attempting to minimize shipments in the current week, current plus next week, 
current plus next 2 weeks, and so on such that the total shipments in those weeks 
is greater than the current existing backlog whose shipment dale is already past 
or in those weeks, plus the forecasted orders whose desired shipment dales lie in 
those weeks 



such that Y bit) a X s|,) + RB + n| - F| - 1) - W|- 1) 
i=0 r = 0 

and Wnl>0. 

Again, Ihe above is a series of |N 0 +D linear programming problems, with optimal 
feasible solutions that are expressed in closed form as follows: 



b(n) = max 



n-l 



0. F(B + n) + y s(lt - F| - 1) - Wl- II - "f bftl 
i=o t=n 



lor n = 0. 1 % 

To summarize the above, the current build plan should look as follows: 

Week: 0 1 2 ... n 

Planned Build: btO) Wl U2) ... bin). 

1-7 Actual Units Started 

The actual units started this week, bo. will be inWif there is sufficient material If 
there is insufficient material the actual units started is the maximum possible with 
the available material, or: 

Maximize by 

such that Qjb 0 £ R,H ) * r,|0), VjeJ 
andO<bo<W/ 

for which the closed form solution is: 



b n = mm 



)l mm 



Ri(-D+ M 



171 
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1-8 Material Requirement Analysis 

If the lead lime for a part j is L, weeks, the RPI level for part | at the end of weeks 
0,1, ... L-1 has been determined by material on hand, material on order, and 
projected use. We could control RPI for part j at the end of week L, or later by 
deciding how much of part j we order in this week and subsequent weeks. The 
estimated material consumption during a week is the quantity of the material for 
the build for that week, that is: 

q,W=qW'/ |8| 

The material ordered during weeks 0 through n must be greater than or equal to the 
material consumed during weeks 0 through Lj+n plus the desired safety stock at 
the end of week L,+n minus the current on-hand material and the current on-order 
material This can be expressed mathematically as follows: 

Minimize m^n). n = 0,1 N,, jeJ 



n 

such that Vmyftl a Y, + r i( l i + n ) - R |l-H ~ 0,( — 1 > 

t=0 1=0 
and i^lnlz 0 

After substituting equation 8, this becomes a series of linear programming 
formulations for which the closed form solution is: 



r 



mfn} = max^ 



L j+ n 

Q, £ fiW+R^Lj + nj-RjI-l) 

m i 

n-1 \ 
- 0,1-1) - V mfl)\ 



forn = 0, 1 Nj.jeJ 

The current material ordering plan is shown by the following table. 









Week 






0 


1 


2 


n 


Material 1 


m,(0l 


m,IU 


nnffl 


m,lnl 


Material 2 


wtoi 


m?W 


m 2 l2) 


m 2 lnl 


Material | 


mjlO) 


mill) 


ii0 


mjlnl 



1-9 Actual Material Ordered 

Given the table above, the actual material ordered in this week must be m/0/ 
VjeJ 



1-10 Determination of the Required Number of Weeks 

Since we want to compute the material procurement plan for material j for periods 
0 through Nj, we need to make sure we have values of the forecasts, shipment 
plan, and build plan far enough in the future to allow us to do so This section 
shows how many periods of those plans we need to compute. 

In 10 through 16 below, "n)(n) requires x|n|" should be read as. "Computing mjlnl 

requires values of x(0), x(1) x(n|."Thus 10 should be read as. "Computing 

m/A}/ requires the values of ff/fl/ Ml fl ( //,+/V y /" 

From 9, 

mjINjI requires Rj|Lj + N|) 

and ny/V,y requires 6fy + A}/ 
From 10. 3. and 1, 

/T^YAjyrequires f(L, + N, + 13). 
From 11 and 6, 

tqlNjl requires RB + Lj * Nj) 

and m/Aj/requires s(B + /, + AJ/ 
From 13, 2, and 1, 

m/A/ ; /requiresf(B + 1^ + 1^ + 13) 
From 14, 5, and I, 

m/A/,J requires f(B + L | + N ( -|Y-S)| 
Computation of Nt,. From VI, 

N h = maxlL; + N. . 



Computation of N 5 . From 14, 

N 5 = maxlB + L, + N, 
iejl 1 1 

Computation of Nf. From 12. 15, and 16, 



N| = max-4 

iej 



L, + N, + 13 

B + L, + N, + 13 

B + L + N, - |Y - S) 



(10) 
111) 

112) 

1131 
114) 

1151 

116) 

1171 
1181 

(19) 



Since B > 0. (Y - SI > 0, the middle expression dominates, and 1 9 reduces to: 



iej 



N, = max|B + L, + N, + 13 



1201 



Appendix II: Weekly Event Sequence 

In the following table, periodically scheduled events are shown in sequence. 



Event Time 


Event Frequency 


Initiators 


Event Description 


Monday 1:00 


Weekly 


Customers 


Generate and send orders; these orders are received by the Adder factory at 9:30:00 the same day 


Monday 8:00 


Weekly 


Factory 


Completes computing FGI safety stock for future weeks Completes computing shipment plan and 








build plans. 


Monday 9:00 


Weekly 


Factory 


Completes computing material requirements plan Completes computing material procurements plan 


Monday 10:00 


Weekly 


Factory 


Generates current week's material orders. Material orders arrive at the vendors instantaneously 


Monday 10:00:01 


Weekly 


Vendors 


Finish filling and shipping orders due this week Shipments arrive at the factory instantaneously. 


Monday 10:30 


Weekly 


Factory 


Begins current week's production Completes production started two weeks ago 


Friday 16:30 


Weekly 


Factory 


Completes filling and shipping orders for the week 


Friday 23:58 


Weekly 


Simulation Executive 


Records values of all the state variables. 
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Appendix III: Details of Part Commonality Experiments 



The following Table shows the Definitions used to describe pari commonality MC 
stands for material cost, with uppercase denoting dollar values and lowercase 
denoting percentage values m represents its set of material 



Set ol Value ol 
Material Material 



Percentage 
Value 



Common to products 
i and >-l 

Unique to product I 



Common to products 
i and i+1 



BfeM 



MC,, 



MC,. 



mc u -i = 



MC.j - 1 



mc,, = 



MC 

MC, , 



x 100 



MC. 



x 100 



MC,,,, 
MC, 



x 100 



Commonality occurs only between adjacent products This implies that a part can 
be used in at most two products 

Each of the MCy is further broken up into class A, B, and C pans with relative val- 
ues 50. 30. and 20 percent Each of these classes is made up of 6. 10. and 14 week 
lead times with relative values 25, 40. and 35 percent. (See Table I on page 83.I 

At the end of the product i life cycle, obsolete inventory (if any) should come only 
from parts in sets m, , and m, Any leftover parts from m, ,,, can be used in 
product i+1 This implies that mc, ,i and mc M impact the obsolete inventory at the 
end of the product life cycle for product i 

The values shown in the following table should be derived from the real bill of 
materials. For our experiments, we reverse the process, that is. we generate a bill 
of materials from the table, which was generated heuristically from the experi- 
mental scenarios, with the following constraints on the values nf mc 



• for each i and |. mc, , must be greater than or equal to 0 and less than or equal to 
100 

• for each i the sum of mc, i over all j must be 100 

• In each experiment if any mc, >s zero, then mc,., , must also be zero 

Description of Experimental Scenarios 

Run M-Ch no part commonality at all between adjacent products 

Run KM: 20% pan commonality between adjacent products The pans common 
to products i and itl make up 20% of the part values of both products This may 
happen by a reduction in either part quantity or part cost, but the reason is not 
reflected in the dollar value of leftover inventory or material 

Run KI-2: 20% pan commonality when moving to a new product The pans com- 
mon to products i-1 and i make up 20% of the pan value of product i. the rest of 
the value of product i is split equally between the parts unique to product i and 
those common to products i and W Since product Adder-1 has no prior product, 
the value is split equally between unique pans and pans common to Adder-1 and 
Adder-2. 20% of the value of Adder-2 is made up of pans common to Adder-1 and 
Adder-2. the remaining 80% is split equally between unique pans and pans com- 
mon to Adder-2 and Adder-3 20% of the value of product Adder-4 is made up of 
parts common to Adder-3 and Adder-4; the balance of the value is unique parts 
since there are no succeeding products 

Run M-3: 50% and 25% part commonality between alternate products. There is 
50% part commonality between products Adder-1 and Adder-2 and between 
Adder-3 and Adder-4. there is 25% pan commonality between Adder-2 and 
Adder-3. 

Run KM: 50% part commonality between adjacent products, no unique parts in 
Adder-2 and Adder-3; 50% unique parts in Adder-1 and Adder-4. 



Run M-5: 80% part commonality between succeeding products 
Part Commonality Data (%) for Multiple Product Crossover 



i 


Product 


Demand (units) 


Product Cost (SI 


Common Parts (%) 






Experiment Run 
















M-0 


M-1 


M-2 


M-3 


M-4 


M-5 


1 


Adder-1 


V 


10,000 




100 


80 


50 


50 


50 


20 












0 


20 


50 


50 


50 


80 


2 


Adder-2 


1,3V 


0.85 x 10.000 


mcj.i 


0 


20 


20 


50 


50 


80 










mC2.2 


100 


80 


40 


25 


0 


10 










mc2.3 


0 


20 


20 


25 


50 


10 


3 


Adder-3 


1 3x1.3V 


0.85x0.85x10,000 


mC3.2 


0 


20 


20 


25 


50 


80 










mc 3 .3 


100 


60 


40 


25 


0 


10 










mc 3 , 4 


0 


20 


40 


50 


50 


10 


4 


Adder-4 


1.3x 13x1.3V 


0.85x0.85x0.85x 10,000 


mc 4 .3 


0 


20 


20 


50 


50 


80 










mc 4,4 


100 


80 


80 


50 


50 


20 
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Appendix IV: Details of Explanations for Experiments 0 and la 



IV- 1 Estimated Financial Impact Based on Theoretical Considerations lor 
Experiment 0 

The impact of product Adder on the financial situation at the enterprise, as 
explained on page 89. is: 

• Total PCFT = $7,800,000 

• Mature volume = MV = mature PCFT = SBOO.OOO/month or $200.000/week 

• Consignment inventory = S300.000. 

IV-2 Mature Demand Week Considerations for Experiment 0 

RPI Material to Support Mature Demand 

Class A Class B Class C All Classes 

© Percentage of Part 50% 30% 20% 100% 
Value in Product 

@ Weekly Use during $100k S60k S40k S200k 
Mature Demand 
©xMV 

<3> RPI Safety Stock in 4 8 16 N/A 

Weeks 

® RPI in S: <J> x MV S400k 

® RPI in Weeks of MV 2 
® + MV 



S480k S640k SI 520k 
24 3.2 7.6 



On-Order Material to Support Mature Demand 

I Lead Time 6 weeks 10 weeks 14 weeks All Parts 

25% 40% 35% 100% 



3 Percentage of Pan 
Value in Product 



Weekly Order during $50k 
Mature Demand 
8 x MV 



S70k 



$200k 



3 Amount on Order = S300k S800k $980k S2080k 
Weekly Order x Lead 

Time: ® x ® 



& Percent Value of Part 14.4% 38.5% 471% 
on Order <$ + $2080k 

® On-order Material in 1 5 4 0 4.9 

Weeks of MV 
® + MV 

Total Inventory Metrics during Mature Demand 



100% 



10.4 





Weeks of 


Dollars 




Mature Demand 




$ RPI 


76 


S 1520k 


® WIP 


2.0 


S400k 


B FGI 


20 


S400k 


® On-Hand Inventory: ® + ® + ® 


11.6 


S2320k 


Si On-Order Material 


10.4 


52080k 


® Committed Inventory 8 + -9/ 


22.0 


S4400k 


® Consignment Inventory 


1.5 


S300k 


® Total Committed Inventory: ® + ® 


235 


S4700k 



IV-3 End-of-Life Considerations for Experiment 0 

Total PCFT = S7.800.000 Net profit = $78,0001 i/1 00). where i is the profit as a 
percent of PCFT. 

The following table summarizes the impact on the profitability of various margins i 

Write-Off as a Function of Profit on Shipped Units 

® Profit Margin i 5% 10% 20% 30% 

S390k $780k S 1560k $2340k 



0 Profit from Trade Units 
S7 8Mx® 

3 Leftover Material 



$64,615 



® Leftover Material as % of Net 16.57% 8.28% 4.14% 2 76% 
Profit®*® 

® Consignment $300,000 

® Consignment as % of Net Profit 76.92% 38.46% 19 23% 12 82% 
® + ffi 

® Total EOl Material as % of Net 93.49% 46.75% 23.37% 15 58% 
Profit. (® + ®) + ® 

The following table shows the impact on Class C EOL material of reducing safety 
stock levels These results were computed using means other than simulation 



Weeks of Class C Safety Stock 

16 weeks 
15 weeks 
14 weeks 
13 weeks 



Class C EOL Material 

$64,615 
$35,385 
$13,846 
$0 



IV-4 Why There Is Class C material Left Over for Experiment 0 

The last period m which we expect to receive orders is week 68 The end of week 
55 is 13 weeks before the end of the product life cycle. From the Adder order fore- 
cast in Fig 2 on page 83 and the target RPI safety stock for class C material being 
16 weeks of the 13-week leading average forecast (Table lb on page 831, at the end 
ot week 55 the amount of class C material in RPI should theoretically be 16/13 of 
the total demand to the end of life, or (16/13) x (1% x V| = 128/13) x V units, 
where V = 80. 

In week 56, we need to start building the units for orders received in week 55 
Ignoring the current FGI, the maximum new build from week 56 to the the end of life 
is equal to the demand from week 55 through the end of life, that is, 2V Thus, at the 
end of week 55, there is more class C material on hand — enough to build (28/13) 
x V units— than needed for the demand to the the end of the product life cycle 

Remember that we did not consider units in FGI If we want to reduce FGI units 
down to 0 bv the end of the product life cycle, the total new build must be less than 
that computed above, and hence there will be even more class C material left over 

In summary, one reason for the leftover class C material is that the safety stock 
computation requires holding more class C raw material in RPI 13 weeks before 
the end of life than can be consumed bv orders received in the last 14 weeks of 
the product life cycle 

IV-5 Why Orders Cannot Be More than 14 Weeks Late for Experiment 1a 

Assume that an order comes in during week x In the worst case we have not yet 
ordered any material for the unit that goes with this order The earliest the material 
can be ordered is week x+1. and the longest lead time part will be delivered during 
week (x+1 )+14, which is week x+I5. Since build time is 2 weeks, the unit is ready 
in week x+1 7 Since transit time is 1 week, the unit is delivered to the customer in 
week x+18 Since the quoted availability is 4 weeks, on-time delivery means the 
customer should receive it in week x+4 This means that the lateness is 14 weeks. 
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February 1994 

High-Quality Color Inkjet Office Printers. Doui/las R. Watson and 
Halein E. Mustafa 

Laser-Comparable Inkjet Text Printing. Jaime II. Boluiiyiie:. Brian 
P. (a afield, Kenneth J. Courian, Frank Dmgo, CorrilM A.E. Hall. 
Clayton L. Holslvn, Anepsa R. Scandalis. and Michele E. Site/Hint 
An Inside View of the Drop Generation Process 
Modifying Office Papers to Improve Inkjet Print Quality 

High-Quality Inkjet Color Graphics Performance on Plain Paper, 
Catherine B. limit. Ranald A. Asketand. Leonard Slerin. and 
Keshaea A. Prasad 

Polyester Media Development for Inkjet Printers. Dan iel L Hriley 

Inkjet Printer Print Quality Enhancement Techniques. Corinnn A.E. 
Hall, Anecsa R. Scandalis, Damon W. Binder. Shelley I. Moore, 
Reza Uovaghar, W. Wistar Rhoads. and William H. Sehirielierl 

The Third-Generation HP Thermal InkJet Prinihead. •/. Stephen 
Aden, Jaime II. Bohoiyuez, Do aulas M. Collins, M. Douglas trunk. 
Aildiv Garcia, anil I'lrieh E. Hess 

Development of the HP DeskJet L200C Print ( ai t ridge Platform, 

(he Platform Devebrpmeni Team 

Print Cartridges for a Large-Format Color Inkjet Drafting Plotter 
Environmentally Friendly Packaging 

HP DeskJet 11200C Printer Architecture. Kevin M. Boekiutiu. Anton 
Tallin: Era! Ertiirk. Robert R. Giles, and William II Schieiebeii 

< AD System ( Irganizal ion 

Product Design Effect on Environmental Responsibility and 

Distribution Costs 

A New Product Development Model 

flint Cartridge Fixturing and Maintenance in the HP DeskJet 1200C 
Printer. Michael T. Dangelo, Reza Morai/lini; and Arthur K. Wilson 

Media Path for a Small. Low-Cost. Color ■Thermal Inkjet Printer. 
Damon W. Header, Daeid ( '. Harney, Shelley I. Moore, and Slephen 
H. Wilte 

Stepper Motor Simulation Model 

Automated Assembly and Testing of IIP DeskJet 1200C Prim 
Cartridges. William S. ('album. Randell A. Ayadoni. Michael M. 
Johnson, Edward Wiesmeier. Ill, and Cli n Oldeiibniij 

Connectivity of the UP DeskJet laKJC Printer. Anthony D. I'arkhurst, 
Ramcliandmn Padmanahhaii. Slmmt D. Mueller, and Kil l A. Winter 

April 1994 

Development of a Multimedia Product for IIP Workstations, Gary P. 
Rose, Jeffery T. Oeslerk; Joseph E. Kasper, and Robert J. Hammond 



HP MPower. A Collaborative Multimedia Environment, William R. 
Yoiler 

X Stations in HP MPower 

The HP Instant Ignition Program 

Diagnosing and Reporting Problems in the Multimedia Environment 

A Graphical User Interface for a Multimedia Environment. Cluiiies 
V. Fernandez 

HP SliaredX: A Tool for Real-Time Collaboration. Daniel Garfinkcl. 
Bruce c. Welti, and Thomas W. Yip 

X Window System Client/Server Architecture 

Graphics Glossary 

Whiteboard: A New Component of HP SliaredX 

Imaging Sen il es in a Multimedia Environment. Andrew Mnum ami 
Ahmad II. Sliekarabi 

HP Image Library Scaling Functions 

A Printing Solution fora Multimedia Environment, Maudler 

Faxing Documents in HP MPower, Francis P Sunt/ ami Mark A. 
■loll nson 

Audio Support in HP MPower, Ellen A'. Ilramll. Thomas G. Einclirr. 
and Moaish S. Shah 

Overview of A-law and u-lavv Data Formats 

Video Support in a Multimedia Environment, Cratg S. Richard 

Mail Facilities in a Multimedia Environment, Robert B. Williams. 
llaiTy K. Phiiiiiii/. ami Kenneth I.. Slcci/c 

MIME Header Fields 

A Fast and Intuitive Online Help System. Michael R. Wilson. Lori A. 
Cook, and Sleren P Ilichrrt 

WYSIWYG Printing in an X Application 

Developing Online Application Help. Dec Smith 

June 1994 

Corporate Business Servers: An Alternative to Mainframes for Busi- 
ness Computing, nomas B Ale.i under. Kenneth G. Robertson. 
Dean T. Lindsay. Donald I.. Royers. John R. Obermeyer. John R. 
Keller, Keith Y. Oka. and Martin M. Jones. II 

Package Design Using 3D Solid Modeling 

PA-RISC .Symmetric Multiprocessing in Midrange Servers, Kirk M. 
Bresn iker 

Soflrlench Message ( onneiior: ( ustomizing Software Development 
Tool Interactions. Joseph J. t 'ourunl 
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Six-Signm Software Using Cleanruoin Software Engineering Tech- 
niques, Grant E. Head 

Ix-gal Primilive Evalualion 

Fuzzy Family Setup Assignment and Machine Balancing. Jan Krttcky 
The Greedy Board Family Assignment Heuristic 

August 1994 

An Advanced Scientific Graphing < aleulator, Diana K. Byrne, 
Charles M. Palton, David A met I, Ted W. Beers, and Paul J. 
McClellan 

User Versions of Interface Tools 

HP-PAC: A New Chassis and Housing Concept for Electronic Equip- 
ment, Johannes Maim, Jilrgen Hdberlc, Siegfried Kopp. and Tim 
Sell ucgler 

High-Speed Digital Transmitter Characterization Using Eye Diagram 
Analysis, ('hrislopher M. Miller 

Thermal Management in Supercritical Fluid Chromatography, 
f 'annir Nathan and Barbara A. Hackbarlh 

What is SFC? 

Linear Array Transducers with Improved Image Quality for Vascular 
Ultrasonic Imaging, Matthew G. Muaney and Martha Ginve Wilson 

Structured Analysis and Design in the Redesign of a Terminal and 
Serial Printer Driver, Catherine L. Kile/vase 

Data-Driven Test Systems, Adelc S. Landis 
October 1994 

Customer-Driven Development of a New High-Performance Data 
Acquisition System, Von C. Campbell 

A Compact and Flexible Signal Conditioning System Tor Data 
Acquisition, Jolt n M. da Curtha 

High-Throughput Amplifier and Analog-to-Digital Converter, 
Ranald J. Rieilcl 

Binary Ranges Speed Processing 

On-the-Fly Engineering Units Conversion, Christopher P.J. Kelly 

Buill-In Self-Test and Calibration for a Scanning Analog-to-Digital 
Convener, Gerald I. ftaak and Christopher P.J. Kelly 

A Hierarchy of Calibration Commands 

Manufacturing Test Optimization for VXI-Based Scanning Analog-lo- 
Digital Converters, Bert mm S, Kolts and Rodney K. Village 

Design Leverage and Partnering in the Design of a Pressure Scanning 
Analog-to-Digital Converter, Richaiil E. Warren and Conrad R. Profl 

Integrated Pin Electronics for Automatic Test Equipment, James W. 
Grace, David M. DiPielro, Akito Kishida, and Kenji Kinsho 

CMOS Programmable Delay Vernier, Masaharu Goto, James 0. 

Barnes, and Ronnie E. Owens 

Theoretical Approach to CMOS Inverter Jitter 

Real-Time Digital Signal Processing in a Mixed-Signal LSI Test 
System, Keita Gunji 



Vector Error Tesling by Automatic Test Equipment, Koji Kambe 
High-Frequency Impedance Analyzer, Takanori Yonekura 
Virtual Remote: The Centralized Expert. Hamish Butter 
Frame Relay Conformance Testing, Martin Ditbue 
Glossary 

The FDDI Ring Manager for the HP Network Advisor Protocol 
Analyzer. Sunil Bhat, Bab Kroboth, and Anne I.. Driesbaeb 
Fl >Dl Topology Mapping, Sunil Bhat 

Automation of Electrical Uverstress Characterization for 
Semiconductor Devices, Cailos II. Diaz 

December 1994 

Fasl DDS-2 Digital Audio Tape Drive. Damon R. I [jrorasy 

DDS-2 Tape Autoloader High-Capacity Data Storage in a 5%-Inch 
Form Factor. Steven A. Dimond 

Autoloader Control Electronics 

Autoloader Firmware Design 

Network Backup with the HP C1553A DDS Autoloader 

Aulomalic State Table Generation, Mark J. Simms 

Using State Machines as a Design and Coding Tool. Mark J. Simms 

An Event-Based, Retargetable Debugger. Aran K. Iyengar, 
Tliaddeus S. Grzesik, Valerie J. Ho-Gibson. Traey A. Hoover, and 
John R. Vasla 

Compiler Optimizations and Debugging 
A Short Primer on Debugger Internals 

Wavelet Analysis: Theory and Applications, Daniel T.I.. Lee and 
Akio Yamnmota 

Approaches to Verifying Operational Test Release Vectors, 
Joy Xiao Htm 

OverView of the Test Access Poll 

Estimating the Value of Inspections and Early Testing for Software 
Projects. Louis A. Franz and Jonulltan C. Shih 

Clock Design and Measurement Issues in Pentium™ Systems. 
Michael K. Williams and Andreas Pfu ff 

Tolerance Mechanisms in Clock Distribution Networks 

Enterprise Modeling and Simulation: Complex Dynamic Behavior of 
a Simple Model of Manufacturing. M. Shahid Mujtaba 

Glossary of Terms and Abbreviations 

Enterprise Modeling iuid Simulation Applications in Reengineering 
Enterprise Modeling and Simulation Research al IIP Laboratories 
The Simple Model: Sponsor's Perspective 

Appendix I: Mathematics of Production and Material Planning for 
the Simple Model 

Appendix II: Weekly Event Sequence 

Appendix III: Details of Part Commonality Experiments 

Appendix IV: Details of Explanations for Experiments 0 and la 
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Part 2: Subject Index 



Subject Page/Month 
A 

Abstract test suite 84/001 

Accuracy, media drive TS/Feb. 

Acoustic impedance 43/Aug. 

Actual-to-forecast ratio 91/Dee. 

Algorithm, logical mapping 100/OoL 

Algorithm, physical mapping 102/Oct. 

Alignment, print cartridge 39/Feb. 

A-law and ji-law data formats 65/Apr. 

Analyzer, eye diagram 31/Aug. 

Analyzer, impediuice 67/OcL 

Analyzer, protocol 88/OcL 

Analyzing wavelet 45/Dec. 

Annotating images 28/Apr. 

Amibaeklash device 75/Feb. 

Aperture, ultrasound 45/Aug. 

Application help use model 90/Apr. 

Arbitration 12/June 

Architecture, inkjet printer 56/Feb. 

Area fill quality 18/Feb. 

Assembly, print cartridge 79/Feb. 

Audio editor 62/Apr. 

Audio file types 63/Apr. 

Audio hardware 60/Apr. 

Authoring, help system 94/Apr. 

Autoloader, DDS tape 12/Dec. 

Automatic lest pattern generator 

(ATPG) 55/Dec. 

Availability 82, 95/Dec. 

B 

Iiackup. data 6. 12, 18/Dec. 

Bag, ink 49/Feb. 

Balinkin transfonuation 24/Feb, 

Banding 19/Feb. 

Basis functions 44/Dec. 

Beam width, ultrasound 45/Aug. 

Bill of materials (BOM) &VDeo. 

Bit error ratio tests 29/Aug. 

Bilonal 37/Apr. 

Bleed 19, 29/Feb. 

Blocking 20, 31/Feb. 

Branching, tool interaction 35/June 

Bus converters 17/.Iune 

Busying a transaction 11/June 

c 

Calculator, scientific (i/Aug. 

Calibration. HI' Ki ll.') 19, 25/Oct. 



Calibration, delay 56/Oct. 

Calibration, impedance. 

modified OSL TfJ/Ocl. 

Callback functions 37/Dec. 

Capability index 40/June 

Cavitation 42/Feb. 

CHAMP I channel-reseller 

and manufacturing process) 17/Apr. 

Oiaining, tool interaction 35/June 

Charged-device model 107/Ocl 

Chassis. foam 23/Aug. 

Chirplet analysis 52/Dec. 

Chirplet transform 52/Dec. 

Choose boxes 15/Aug. 

Cleanroom software 

engineering 41/June 

Client/server architecture. 

HP MPower 13, 25. 64/Apr. 

Clock distribution, Pentium 68/Dec. 

Clock measurements 74/Dec. 

( 'oalescence 19/F eb. 

Cockle 18/Feb. 

Coherent write buffers 15/June 

Collaboration 23/Apr. 

Color degradat ion 88/ Apr. 

Color flow imaging 44/Aug. 

Color management 31/Apr. 

Color matching 32/Apr. 

Color optimization 24/Keb. 

Color quality, inkjet 18/Feb. 

Color ramp 32/Apr. 

Colorants 33/Feb. 

Commentator, FDDI 90/Oct 

( 'omparator, pin 43. 45/Oct. 

Compiler optimizations 37/Dec, 

( 'omponenl placement 

tuacliines 51/June 

( 'omputers. busini?ss servers ... (5, 31/June 

Conditioners, for 1C testing 58/Dec. 

Connector. HP Shaied.X 20/Apr. 

Contact angle, ink 30/Feb. 

Conlenl types, MIME 76/Apr. 

Context iliagram 5(i/Aug. 

Contextual help Hi/Apr. 

Control flow diagram 54/Aug. 

Control specification 51/Aug. 

Core server, IIP SharedPrinl 47/Apr. 

Covered ROM 9/Aug. 

Cracking 31/Feb. 

Crystallization 32/Feb. 

Curl 18/Feb. 

( 'urrent-mode amplllier 17/Oct. 
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Current-voltage impedance 

method 68/OcL 

Cyanate ester 2&'June 

D 

DAT drive 6/Dec. 

Data dictionary 54/Aug. 

Data-driv en test systems 62/Aug. 

Data flow diagram 54/Aug 

Daubechies wavelet 47/Dec. 

DDS autoloader 12/Dec. 

DDS-2 tape drive 6/Dec. 

Debugger internals 39/Dec. 

Debugging optimized code 34/Dec. 

Defect-free software 40/June 

Delay line structures 53/Ocl. 

Delay vernier, CMOS 51/Oct. 

Design leveraging 35/Oct. 

Design margin 19/Dec. 

Design plots 99/Dec. 

DesignJet 650C printer 6, 50/Feb. 

DeskJet 1200C printer 6/Feb. 

Desktop configurations 14/Apr. 

Detector, flame ionization. SFC . . . 41/Aug. 

Diagnostics, HP MPower 18/Apr. 

Differential equations 2I/Aug. 

Digital signal processing. 

LSI tester 59/Oct 

Digital transmitter 

characlerizalion 29/Aug. 

Digital \ideo 8/Apr. 

Directional bridge 68/Oct. 

Display modules 95/()ct. 

Display resources and rendering .. 31/Apr. 

Distributed multimedia 12/Apr. 

Distributed priority list 

arbitration 12/June 

Dithering 40/Apr. 

Dot gain 26, 30/Feb. 

Drawing modes 87/Feb. 

Drive roller. Inkjet printer 74/Feb. 

Driver, pin 43, 44/Ocl. 

Driver redesign 52/Aug. 

Or MPower 18/Apr. 

Drill-down 94/Ocl. 

Drop detection 82/Feb. 

Drop general ion, inkjet 11/Feb. 

Drop placement errors 18/Feb. 

Drop size, InkJet 10/Feb. 

Drop volume, inkjet 12. 20/Feb. 

Drum, tape drive O/Dec. 
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Drying time 28/Feb. 

DSP module 61/Oct. 

Dual-frequency transducers 50/Aug. 

Duplicate cache lags 14/Juue 

Dye selection 24/Feb. 

E 

Edge (|iiality, inkjet 18/Feb. 

Klectrical overstress testing 106/Oct. 

Electrical system, inlget printer , . . 02/Feb. 
Electrostatic discharge testing . . . 106/Oct. 

Engineering tuiils conversion 21/Oct. 

Enterprise modeling 

and simulation 80/Dec. 

EPP foam chassis 23/Aug. 

Error diffusion 91/Feb. 

Error trace capture 36/Aug. 

Event-based debugging 33/Dec. 

Event matrix 55/Aug. 

Events, calculator IG/Aug. 

Evolutionary delivery, 

cleanroom 42/June 

Excitation supply 1 4/< )cl . 

Executable test suite 84/Oct. 

Expanded polypropylene 23/Aug. 

Expression evaluation 39/Dec. 

Extinction ratio 30/Aug. 

Eye diagram analyzer 31/Aug. 

Eyeline diagram 32/Aug. 

F 

Fax client 54/ Apr. 

Fax databases 55/Apr. 

Fax server 55. 59/Apr. 

Faxing documents 9, 53/Apr. 

FDD1 King Manager 88/Oet. 

FGI 82. 85/Dec. 

File manager. HP VUE 3.0 21/Apr. 

Filters, printing 49/Apr. 

Filters, root raised-cosine 64/Oct. 

Firmware design, autoloader 15/Dec. 

Firmware, inkjet printer 04, 85/Feb. 

Fixtures, impedance 

measurement 73/Oct. 

Foam chassis 23/Aug. 

Forecast quality 80. So/Dec. 

Foreign language format, 

HP Help System 85/Apr. 

Frame relay 

conformance testing 83/Oct. 

Functional verification 43/June 

Fuzzy composition 56, 01/June 

Fuzzy family assignment 

heuristic 57/June 

Fuzzy logic 51/June 



Fuzzy logic, HP E 14 13 33/Oet 

Fuzzy relations 56/.lune 

Fuzzy set llieory 54/June 

G 

Gahor transform 44/Dec. 

Gamut, color 18/Feb. 

General help 92/Apr. 

Graphical user interface 20/ Apr. 

Grayscale 37/Apr. 

Greedy hoard heuristic 53/June 

Grid-centered method 90/Feb. 

Grid-inlersection method 90/Feb. 

H 

Haar wavelet 46/Dee. 

Hatley-Pirbhai state machine 28/Dec. 

Heads, tape drive 7/Dec. 

Heater. inkjet 15, 23, 32. 36, 73/Feb. 

Help dialogs 81. 84/Apr. 

Help entry points 81.91/Apr. 

Help file compression 

and decompression 84/Apr. 

Help file system 80/Apr. 

Help information models 92/Apr. 

Help-smart application 82/Apr. 

Help use model 90/Apr. 

Help volumes 82/Apr. 

High-Q measurements 70/Oct. 

High-throughput amplifier 16/Oct. 

HP-PAC 23/Aug. 

Human body model 106/Oct. 

Hypertext links 93/Apr. 

I 

IC. delay vernier 51/Oft. 

IC, pin electronics 42, 44/Oct. 

IC, processor interface 14/June 

IC test system, mixed signal 42/Oct. 

TO! function 43/Oct. 

Image compression 

and decompression 39/ Apr. 

Image conversion 41/Apr. 

Image files 37/Apr. 

Image manipulation 41/Apr. 

Image processor 86/Feb. 

Image scaling 41/Apr. 

Impedance analyzer 67/Oct. 

Industry standard file types 39/Apr. 

Ink design, black 13/Feb. 

Ink design, color 23/Feb. 

Ink level indicator 53/Feb. 

Ink-receptive coating 28/Feb. 

Inks, inkjet 33/Feb. 



Input forms 13/Aug. 

Input/output subsystem 10/.!une 

Inspections, code 61/Aug. 

Instrumentation amplifier 17/Ocl, 

Integrated driver printheacl 11/Feb. 

Intellectual control 43/.Iune 

Interpreter, state table 24/Dec. 

Interprocess communication I4/Apr. 

Interval, monitor 99/Oct. 

Interval, update 99/Oct. 

Inventory 85. 88/Dee. 

ISS 

( Instrument Software System) .... 76/Oct. 

Item help 82/Apr. 

1-V impedance method 68/Oct. 

J 

Jitter, clock 68/Dec. 

Jitter. CMOS inverter 54/Oct. 

Jitter, transmitter 36/Aug. 

"Just-enough-iest" strategy 30/Oct. 

K 

Klioros system 48/Dec. 

Knowledge worker 10/Apr. 

L 

L*a*b* system 24/Feb. 

Language interface 92/Feb. 

language, test plan 62/Oct. 

Language, TTCN 84/Oct. 

bmguages. test suite 84/Oct. 

Large-format plotter 50/Feb. 

Lead t ime 82, 85/Dec. 

Legal primitive evaluation .... 45, 47/,Iune 

Level 1 diagram 56/Aug. 

Library, operation modular 62/Oct. 

Line quality, inkjet 18/Feb. 

Linear phased-array transducers . . 46/Aug. 

Linearity, tape drive 9/Dec. 

Load, active 43, 45/Oct. 

Loealizability 89/Apr. 

LSI test system, mixed signal 42/Oct. 

M 

Machine balancing 53. 59/June 

Machine model. ESD 106/Oct. 

MACless nodes 105/Oct 

Magazine, tape autoloader 14/Dec. 

Mail composer 74/Apr. 

Mail system 71/Apr. 

Mail transfer agent 73/ Apr. 

Mail user agents 72/Apr. 
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Management information base 

<M1B) 88.98/Oct. 

Managing shared windows 3<VApr. 

Manufacturing, computer 2&'June 

Manufacturing 

enterprise model 82, 90/Dec. 

Manufacturing test optimization . 3u/Ocl. 

Map. physical 89. 97. 102/Oct. 

Map. logical 89. 97. 100/Oct. 

Mapi>lng, FDDI ring 

topology 89, 94. 97/Oct. 

Mask measurements 36/Aug. 

Matching fonts 34/Apr. 

Mathematics, calculator 19/Aug. 

Maxiclient 15/Apr. 

Mealy state machine 27/Dec. 

Measurement modules, 

HP 1102000 7/0ct 

Mechanical design, 

tape autoloader 14/Dec. 

Mechanical design, computer 26/June 

Mechanical design, inkjel printer . . 58/Feb. 

Media path, inkjel printer 72/Feb. 

Memory configurations, HP 48GX . . 7/Aug. 

Memory interleaving 19/Jime 

Memory size conventions 9/June 

Memory system 19/June 

Message Connector, Soft Bench . . . 34/June 

Metamail 75/Apr. 

Meyer wavelet 46/Dec. 

MIME (Mullipuri)ose 

Intemel Mail Extensions) 72, 75/Apr. 

Mimetvpas 78/Apr. 

Miniclient 15/Apr. 

Modes, inkjel printer 21. 35/Feb. 

Mottling 19/Feb. 

Model, development 65/Feb. 

Model, stepper motor 75/Feb. 

Modeling, enterprise 80/Dec. 

Models, 

manufacturing enterprise 90/Dec. 

Module testing 63/Dec. 

Moore state machine 27/Dec. 

Morlet wavelet 46/Dec. 

Mother wavelet 44/Dec. 

Motions, tape autoloader 14/Dec. 

MPEG-1 

(Mining Pictures Expert Group) . . . S/Apr. 

Multimedia editor 73/Apr. 

Mull imedia environment 10/Apr. 

Mull iinedia mail 71/Apr. 

Multiprocessing computers .... 6. 31/June 
Munsell system 24/Feb, 



N 

Neighbor information 9S/Ort 

Network Advisor. FDD1 SSOct 

Network backup 18/Der. 

0 

Office Paper Program 16/Feb 

Online application help MVApr. 

Online help 12, 79/Apr 

Operational test release vectors . . 55/Dec. 

Order-to-delivery time 82. 85/Dec. 

Overvoltage protection 9/Oct. 



Packages. HP DDE 38/Dec. 

Packaging, print cartridge 53/Feb. 

Packaging technology, foam 23/Aug. 

Palette 37/Apr. 

Paper advance, inkjet printer 39/Feb. 

Paper, inkjet 16/Feb. 

PA-RISC 6, 31/June 

Part commonality 99/Dec. 

Partnerships 38/Oct. 

PCL 5C language 85/Feh. 

Peltier cooler 40/Aug. 

Pentium clock design (58/Dec. 

Performance, multiprocessor 21/.Iune 

Pigment dispersion 13/Feb. 

Pipeline. CPU 15/June 

Pipeline, printing 51/Apr. 

Pipelining, HP E1413 20/Oct. 

Pixel mapping 34/Apr. 

Placement machines 51/June 

Plotting. 3D calculator 17/Aug. 

Polyester media, inkjet 28/Feb. 

PostScript printer 6/Feb. 

Precision Bus, HP 19/,Itme 

Preheater. inkjet printer . . . 15. 37. 73/Feb. 

Pressure scanner 37/< )ci 

Prewanniug. prinlhead 13/Feb. 

Primary family 52/June 

Priming, inkjel etui ridge 71/Feb. 

Print can ridge alignment 39/Feb, 

Print cartridge development 16/Feb. 

Print cartridge fixturing (17/Feb. 

Print cartridge maintenance 67/Feb. 

PrinI clienl 4fi/Apr. 

Print quality, 

Inkjet 9, 16, 18, 22. 35. 55/Feb. 

Prim quality tester 80/Feb. 

Primers, color inkjel 6/Feb. 



Printhead. inkjet 4L'Feb 

Printing pipeline 51'' Apr. 

Process specification 54/ Aug. 

Processor board 13/June 

Processor interface chip 14/June 

Processor memory bus 10/June 

Processor modules 13/June 

Product-speofir files 63/Aug. 

Production cost flowthrough 

(PCFT) 82,85/Dec. 

Progressive disclosure 92/Apr, 

Pseudonuidom binary se q u ence . . 29/Aug. 

Puddling 21/Feb. 

Pump. SFC 40/Aug. 

Q 

QFD house of quality 47/Aug. 

Quad 10/June 

Quick help 81,91/Apr. 

R 

Range switching 18/Oct. 

Raster operations 87/Feb. 

Receiver service 26/Apr. 

Reengineering 867Dec. 

Remote debugging 36.40/Dec. 

Resolution enhancement 36/Feb. 

Retargetable debugger 33/Dec. 

RetiUTl-on-investnienl model. 

soft ware inspections 65/Oec. 

Risk assessment, 

software testing 63/Dec. 

ROMPTRs 8/Aug. 

Rolal ion. magazine 16/Dec. 

Routine editor 35/June 

Routine engine 35/Junc 

Routine manager 35/June 

RPI 82. 85/Dec. 

s 

Safety stock 827Dec. 

Sales and inventory 

tracking system 00/Dec. 

Sallen and Key filter 11/OcL 

Sampling, harmonic repetitive 32/Aug. 

Scale, wavelet 45/Dee. 

Scan cell 57/Dec. 

Screen calibrator 95/FeU. 

Seam learns 6/Feb. 

Self-test 25/Oct 

Scinlit /receiver architecture, 

HPSharedX 24/Apr. 
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sendmail 73/Apr. 

Servers, business - 6, 31/Jiine 

Service processor 22/June 

Signal conditioning plug-on (SCP) . . 9/Oet. 

Simple Model 82/I)er. 

Siniulalion. enterprise 80/Dec. 

Six-signia 40/June 

Snoopy proiocol 11/June 

SoftJiench Message ( onnector . . . 34/June 

Software, data driven 62/Aug. 

Software inspections .... 48/June, 131/Dec. 

Software melrics 61/Dec. 

Software tesling 62/Dec. 

Speculative prefetch 18/Jimc 

Speed, inKjet printer 9. 14/Feb. 

Split bank 51/June 

Spray 19/Feb. 

Spring-bag print carl ridge 49/Feb. 

Stability, statistical 158/Dec. 

State table generalion 21/Dec. 

State machines 21. 27/Dec. 

Statistical testing 47/June 

Stepper motor 75/Fcb. 

Slrain guages 13/Oct. 

Structure chart 59/Aug. 

Structured analysis and design . . . 52/Aug. 

Strut-lured data, cleanroom 17/June 

St i i ict tired specifical ions, 

cleanroom 42/June 

Style manager 22/Apr. 

Supercrilical fluid 

chromatography 38/Atig. 

Symbol table 38/Dec. 

Syntax trees 38/Dec. 



T 

Tape, DDS-2 7/Dec. 

Tape drive, DDS-2 6/Dec. 

Telephony 9/Apr. 

Temperalure control, prinlhead ... 12/Feb. 

TEMPOB 9/Aug. 

Test access port (TAP) 56/Dec. 

Test executive 64/Aug. 

Test patients 55/Dec. 

Test phuining 62/Dec. 

Test software, dala-driven fS2/Aug. 

Test system, LSI 42/Oct. 

Test vector development 55/Dec. 

Tesling, print cartridge 79/Feb. 

Text quality, inkjet 9, 35/Feb. 

Thermal cycling 42/Feb. 

Thermoelectric cooler 40/Aug. 

Threeoparnp amplifier 17/Oct. 

Time shift, wavelet 45/Dec. 

Timing environment 69/Dec. 

Tolerance mechanisms 70/Dec. 

Tool interaction 34/.lune 

Transducers, linear ultrasound . . . 43/Aug. 

Transilion informalinn, stale 23/Dec. 

Transmitter characterization 29/Aug. 

Transparency film, inkjet 28/Feb. 
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